Payment matching and dunning

Payment Matching and Dunning is a high-frequency finance process run by a three-person team and an external accountant. It begins whenever new bank movements arrive and open invoices remain outstanding. The team retrieves payment data, attempts to match each incoming payment to an open invoice in the ERP using the payment reference and amount, and posts confirmed matches directly to the ledger. When a reference is missing, malformed or ambiguous, the case is set aside for manual review. The process runs multiple times a day across most working days, producing roughly 7,200 runs per year and consuming around 720 hours of staff time annually.

The second half of the process covers dunning. The team identifies invoices that have passed their due date, determines which of three escalation stages applies to each late payer based on how long the invoice has been overdue and what contact has already been made, and sends the appropriate reminder communication. Stage-three cases, which involve formal escalation, are passed to the external accountant or reviewed by a senior team member before the communication goes out. Every posting, match decision and dunning action must be logged with a traceable rationale to satisfy statutory audit requirements, VAT rules and a seven-year document retention obligation. The ERP holds all invoice and customer records and exposes an API that the external accountant has already used for integration work, making it the natural hub for any automation built around this process.

The recommended path is Hybrid: a structured AI workflow that handles the routine majority of payment matching and dunning automatically, with defined human review gates for exceptions, ambiguous cases and relationship-sensitive escalation decisions. The case for this approach rests on a straightforward observation about the data. Around 85 percent of payment matching cases involve clean references and matching amounts that resolve predictably against open invoices in the ERP. Those cases have no business being handled manually. The remaining 10 to 15 percent, covering missing references, partial payments, overpayments and upstream data errors, genuinely require a human to interpret the situation before anything is posted to the ledger. A Hybrid design separates these two populations cleanly: the automation handles what it can handle well, and a structured review queue surfaces everything else to a named reviewer who approves or corrects before posting is confirmed.

The client has no stated platform preference, which is actually an advantage here. It means the design can be built to fit the process rather than constrained to fit a tool. The ERP API is the natural integration point. It has already been proven in a real integration by the external accountant, which removes a significant build risk and shortens the discovery phase. An external developer with a confirmed budget can build a lightweight matching engine and dunning scheduler on top of that API without introducing proprietary platform lock-in. The solution the team ends up with is one they own and can explain to an auditor, which matters here.

Comparing this to the other scored paths makes the reasoning clearer. A fully automated AI Workflow scores well for the standard cases but has no principled way to handle exceptions without either letting incorrect postings reach the ledger or routing everything ambiguous back to a human queue anyway, which is exactly what the Hybrid design formalises. Traditional Code could automate straightforward matching using rule-based scripts against the ERP API, but payment reference quality is inconsistent enough that hard-coded rules accumulate edge cases quickly and maintenance becomes the dominant cost. RPA adds no value here because the API already provides direct, structured access to the ERP; building a UI-level robot on top of an available API is unnecessary complexity. A fully autonomous AI Agent is inappropriate for a process with statutory audit obligations: every posting must be explainable and traceable to a named decision, and unsupervised agentic action cannot satisfy that requirement reliably. Education alone does not address the volume problem or the cash-flow timing risk.

The compliance dimension reinforces the Hybrid choice rather than sitting in tension with it. The requirement that every automated posting carry a logged, explainable rationale is a design constraint that the Hybrid architecture satisfies by construction. The exception review gate captures the reviewer's identity and timestamp. Stage-three dunning requires explicit human sign-off before the communication is sent. The audit log is written as a byproduct of normal operation, not bolted on afterwards. A fully automated solution would need to recreate all of this as additional engineering; the Hybrid approach builds it in from the start because the human gates are the compliance controls.

The honest tradeoff is implementation complexity and ongoing maintenance. A scripted solution would be faster and cheaper to build initially, but it would also break more often and recover more slowly from changes in VAT rules or ERP schema. The Hybrid approach requires a more careful functional specification and a parallel-run period to calibrate the confidence threshold on the matching engine, but that investment is paid back within the first year at the projected savings rate. The ROI case is straightforward: 720 hours per year at a blended rate of GBP 45 per hour is GBP 32,400 in current annual cost, and a conservative 70 percent automation rate delivers over GBP 22,000 in savings against a build cost that sits well below one year's saving even at the high end of the estimate range.

The two strongest alternatives here are Hybrid and AI Workflow, and the difference between them is not theoretical. A fully automated AI Workflow handles the clean 85 percent of cases perfectly well, but it has no principled way to deal with partial payments spread across multiple invoices, overpayments that need a credit note, or a stage-three dunning letter heading toward a customer the external accountant spoke to last Tuesday. Those cases need a person, and a workflow without a human gate will either stall on them or, worse, make a posting that cannot be explained to an auditor. The Hybrid path keeps everything the AI Workflow offers while adding structured review gates precisely where judgment is required, satisfying both the efficiency goal and the statutory compliance requirement in a single design.

Traditional Code scored lower than both because it solves a different problem. A scripted integration against the ERP API can automate straightforward reference-to-invoice lookups, and it would do that reliably, but the moment a payment reference is missing or malformed, the script hits a condition it was not written for and either fails silently or raises an error with no useful context. Every new edge case becomes a developer callout. At 7,200 annual runs with a confirmed 10 to 15 percent exception rate, that maintenance burden accumulates quickly and erodes the cost savings the automation was supposed to deliver. Hybrid wins here because intelligent fuzzy matching handles the ambiguous cases gracefully, routing genuine judgment calls to a human rather than breaking.

RPA was ruled out early because the ERP already exposes an API. RPA earns its place when there is no API and screen-level automation is the only option; using it here would introduce fragility without adding capability. An autonomous AI Agent was similarly ruled out, not because the technology is immature, but because unsupervised financial postings subject to VAT rules and a seven-year audit trail requirement carry compliance risk that no efficiency gain justifies. The Hybrid design captures the speed and intelligence of an AI-powered workflow while keeping a named human accountable for every posting that carries any doubt.

The build starts with two weeks of ERP API mapping. The external developer, working alongside the external accountant who has integrated with the ERP before, documents every relevant endpoint: invoice retrieval, payment status updates, customer records and posting confirmation. At the same time, the finance team formalises the dunning rules in writing, defining exactly what triggers stage one, stage two and stage three, and agreeing on the confidence threshold below which a match must go to human review rather than auto-post. The output of this phase is a signed-off functional specification that all parties, including the external accountant, have reviewed, so there are no surprises during the build.

The core matching engine comes next. Bank movements are pulled from the ERP API on a scheduled basis, several times per working day to match the current process frequency. Each movement is run through a matching layer that attempts exact reference lookup first, then falls back to fuzzy matching on amount, date range and partial reference strings. Tools like Python with the rapidfuzz library or a lightweight LLM-assisted classification step can handle the fuzzy layer, depending on what the external developer is most comfortable maintaining. Matches above the agreed confidence threshold are posted automatically to the ERP, and each posting writes a structured audit log entry capturing the match rationale, confidence score, timestamp and the automated actor identity. Anything below threshold lands in a review queue, described with enough context that the reviewer can make a fast, informed decision.

The dunning scheduler runs on a separate cadence, querying the ERP each morning for invoices beyond their due date and checking each customer's contact history to determine which stage applies. Stage one and stage two reminder emails are generated from templates stored in the workflow and sent automatically via the connected email system, with a copy logged against the customer record in the ERP. Stage three is different: the workflow prepares the escalation draft and routes it to a named finance team member for approval before anything is sent. This gate is permanent, not a temporary safeguard, because it protects customer relationships and gives the external accountant a point to flag any customer currently in conversation. A simple customer-level pause flag in the ERP allows any team member to suspend automated dunning for a specific account without touching the broader workflow.

The exception review interface can be as simple as a structured email digest or a lightweight web-based queue, depending on budget. Each item shows the bank movement, the suggested match or the dunning draft, the confidence level and a one-click approve or correct action. On approval, the reviewer's identity and timestamp are captured and appended to the audit log entry, completing the compliance record. The parallel-run phase, running the automated system alongside the manual process for two to three weeks, is used to calibrate the confidence threshold against real payment reference quality before the team cuts over entirely. Go-live is followed by a one-month review where match rates, exception volumes and cash-flow timing are measured against the baseline, giving the team clear evidence of the return and a foundation for ongoing tuning.