What happens when AR automation meets your ERP

A vendor demonstrates matching, dunning, a customer portal and a dashboard, and near the end of the deck there is one line called integration. Most of the delivery risk sits in that line, because every decision the AR layer makes ultimately has to be reflected correctly in the underlying ERP — in a period that is open, against a customer record that exists, using a general ledger account someone in controlling signed off.

I work at Monk, an invoice-to-cash platform. The detail below comes from our implementation team and from customers who have been through an ERP-side integration before, ours or someone else’s. I have collected it because the same handful of things go wrong each time and almost none of them come up before a contract is signed.

Trade receivables across all sectors of the US economy stood at $9.8 trillion at the end of the first quarter of 2026, according to the Federal Reserve’s financial accounts. Those balances live in ERP subledgers, which is where any AR tool’s decision about a payment ultimately has to end up before it counts.

Six Things Have to Post Back Into the ERP

Applied cash. Major ERP platforms provide standard mechanisms for recording customer payments, and a clean full application against open items can generally be handled through standard payment and clearing processes.

Partial application. A short-paid invoice can be treated as a residual item, as a partial clearing that leaves the original open, or as a fresh document for the balance. Each produces a different aging report and a different conversation with the auditor. Pick the treatment before go-live.

Credit notes. Major ERP platforms generally provide native document and posting logic for credit notes, allowing the adjustment to land where finance teams and auditors expect it.

Write-offs. These typically have a native accounting treatment and an approver attached. A write-off is a posting to a bad debt or adjustment account with a tolerance limit and an approver behind it, and in many companies an AR manager can clear a small underpayment while anything larger goes to the controller. If the AR layer proposes write-offs but the approval chain lives in an ERP workflow nobody wants to touch, you get a queue instead of automation.

Deduction reason codes. This is where the picture becomes less consistent. Depending on the ERP and its configuration, deduction reason codes may require additional fields or workflow design. That is worth settling early because freight, damaged goods, unearned discounts and pricing disputes may need to be routed to four different people.

Promise-to-pay dates. These often sit outside the core accounting record. A promise is a collections artifact rather than an accounting one, and depending on the ERP environment and collections capabilities in place, it may remain in the AR platform rather than flow back into the ERP. That can work perfectly well, as long as everyone understands which system holds that context and what the aging view in the ERP does — and does not — know about it.

One Payment, Three Subsidiaries

The case I see break most implementations is this one. A parent treasury entity sends a single payment that settles invoices raised against three subsidiary customer records, each with its own terms, two of them in another currency.

The remitter name matches none of the three. Payer identification has to resolve to a hierarchy before matching can start, so the AR layer needs to know these records are siblings. That relationship may live in a salesperson’s memory or a spreadsheet called group structure rather than in the customer master.

Then the posting has to split. Where those subsidiaries sit across different company codes or legal entities, the payment may need to be split across multiple application documents, with intercompany accounting required to allocate cash appropriately. Where different currencies are involved, the applications may also create exchange differences that need to be handled correctly.

Plenty of teams route the whole thing through a clearing account and reconcile monthly, which is a reasonable answer provided somebody owns the reconciliation.

Ask any vendor to walk through this case with your own entity structure on screen rather than a demo one.

Start With the Customer Master

Integration gets discussed as an API question. The projects I have seen run late were held up by the state of the customer master instead.

Three faults come up repeatedly.

Duplicate records, where the same buyer exists four times because four salespeople created it, and cash applies to whichever version won the match. Missing parent-child hierarchy, as above. And invoice numbers reused after a migration, so the same number exists twice with different amounts and different dates, creating the risk that an automated match lands on the wrong invoice with full confidence.

Clean all three before the AR layer sees the data.

A deduplication pass, a parent-child field populated for your top accounts by revenue, and a check for repeated document numbers across the migration boundary will do more for your match rate than months of tuning.

Real-Time Posting or Nightly Batch

Real-time posting and nightly batch are both defensible. The part to be clear about is the gap the choice creates.

Under a typical nightly batch model, a payment may not appear in the ERP until the next scheduled synchronization. During that window, a collector looking only at the ERP could still see an open invoice belonging to a customer who has already paid.

Two habits help.

Give collectors a view of unapplied cash as well as applied cash, so they can see money sitting against a customer before it reaches an invoice. Then suppress dunning on accounts holding unapplied cash where appropriate, because a chase sent to a customer who has already paid can do more damage than a short period of silence.

Where These Projects Stall

These projects rarely stall at the API.

Five recurring causes, in rough order of how much time they cost.

A sandbox that does not mirror production, so testing runs against fifty clean demo customers and tells you nothing about the record with the reused invoice number.

A chart of accounts nobody will change, where the deduction and write-off accounts do not exist and creating them needs the controller.

Permissions, because the integration user has to post payments, clear open items and read the customer master, and a security team may review that level of access slowly and only once.

An accounting period that closes mid-implementation, which can turn a cutover week into a lost fortnight.

And no named owner on the ERP side, where finance buys the tool, the ERP is administered somewhere else, and the project waits.

Six Questions to Settle Before You Sign

• Which of the six artifacts posts natively into your ERP today, and which needs a custom field, custom record or workflow somebody has to build and maintain?
• Residual, partial clearing or a fresh document for a short pay — and who in finance made that call?
• Where will the parent-child customer hierarchy physically live after go-live?
• What is the sync window, and what does a collector see inside it?
• Who approves a write-off, and does the approval happen in the AR tool or in the ERP?
• Which ERP administrator is named on the project plan, with time allocated?

The ERP Still Has the Final Say

At Monk, 80% of cash is applied automatically, rising to 95% once suggested matching rules are in place. Those results reinforce a broader point: automation performance depends heavily on the quality and structure of the underlying finance data and on how the resulting decisions are ultimately reflected in the ERP.

I would still rather a prospect spent their first month cleaning the customer master than evaluating us, because the second is wasted if the first has not happened.

Automating the AR layer is a real improvement on people reading remittance PDFs at month end. It only pays once its decisions become postings a controller will sign, so put that half of the project on the plan too.