Accounts receivable: what to automate, what to keep human, and what the data needs

Software can deposit payments, match most remittances to open invoices, post subledger totals to the general ledger and build aging reports. People still need to set policy, resolve payments that fit no invoice, approve write-offs and talk to customers in dispute. Neither works until customer and invoice records are clean.

Steps machines handle well now

Deposits are the easiest place to start. Bank lockbox files, card settlements and electronic transfers arrive in structured formats. A system can record them, total them and reconcile them to the bank statement without anyone touching a keyboard.

Cash application is where most of the effort goes, and where newer tools earn their keep. Rule-based matching clears payments that quote an invoice number and pay the exact amount. Machine learning goes further. It reads remittance emails and PDF advices, links a payment to several invoices, and spots short payments that look like a known deduction. Each correction a clerk makes teaches the model a little more.

The allocation order also belongs with software. Many organisations apply incoming money first to penalties, then to fees, then to interest, then to principal. Once that sequence is written down, a machine applies it consistently every time, which no tired person does at month end.

Recurring invoices for instalment or repayment plans can run unattended. So can interest and late fee assessment, provided the calculation rules are settled.

Posting to the general ledger is close to fully automatic in a well configured system. Subledger activity flows to control accounts in summary. Manual journal vouchers remain for corrections, and those should still route for approval.

Aging reports, collection dashboards and the regulatory receivable returns some organisations must file can all be generated on a schedule.

Steps that still need a person

Policy is a human decision. Credit terms, the point at which an account counts as delinquent, when interest starts and who may approve a write-off all reflect risk appetite and law. Software enforces those choices. It should not make them.

Unidentified receipts need investigation. A payment with no reference, from a payer the system has never seen, may be a miscellaneous receipt, a duplicate or money that belongs elsewhere. AI can suggest a match. Someone with authority has to accept it.

Returned checks and reversed transfers look routine but often signal a customer in trouble. The reversal itself can post automatically. Deciding whether to keep extending credit cannot.

Disputes, credit memos and adjustments involve conversation. A customer claiming damaged goods or a pricing error wants to be heard, and the fix may touch sales, operations or contract terms. Drafting the reply is something AI can help with; agreeing the outcome is not.

The choice to send an old debt to collections, refer it to an outside agency or close it out carries legal and reputational weight. Keep that judgment with a named role.

What has to be true about the data first

One customer should exist once. Duplicate customer records, with slightly different names or addresses, defeat matching faster than anything else. Clean the master file before buying a tool.

Every open invoice needs a unique number that customers can see and are asked to quote. If invoices go out without one, or the number on the PDF differs from the one in the ledger, matching rates will disappoint.

Remittance detail has to reach the system. Where it currently lands in a shared mailbox or on paper, that capture problem must be solved before matching logic can help.

Deduction and reason codes should be defined and actually used. A short payment tagged "other" teaches a model nothing.

The chart of accounts mapping for receivable activity must be stable. If clerks pick ledger accounts by hand, automated posting will copy their inconsistencies at speed.

Historical data for training should reflect how the process works today. Matches made under an old policy or by a departed team can mislead a model.

Questions to ask the people who run it

• When a payment arrives with no reference, what do you actually do first?
• Which customers always pay in a way the system cannot read, and how do you handle them?
• Do you keep a spreadsheet or personal list alongside the system? What is on it?
• Who decides whether a short payment is written off or chased, and is that written anywhere?
• How do you know a returned check has been reversed in the ledger?
• Which reports do managers ask for that the system does not produce?
• What do you fix by hand during close, and why does it keep happening?
• Are interest and fees applied the way the policy says, or are there informal exceptions?
• If you were away for a week, what would break?

The answers usually reveal workarounds that never made it into the procedure manual. Those workarounds are where automation either succeeds or quietly fails.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.