Payment matching and dunning

The finance team receives bank movement notifications multiple times per day on most working days. Each notification contains payment details including a reference field that should identify which invoice the payment settles. The team matches each payment reference to an open invoice in the ERP, applies the payment to close or partially settle the invoice, and updates the customer account. When payment references are clear and amounts align, this matching is straightforward mechanical work. When references are poor, missing, or ambiguous, or when payments cover multiple invoices or arrive as partial amounts, the team must investigate and use judgment to apply the payment correctly.

Once payments are matched and applied, the system identifies customers with overdue invoices and escalates them through a three-stage dunning process. The first stage is a polite reminder, the second is firmer, and the third threatens formal collection action. The team does not blindly follow this sequence for all customers. Good customers with strong payment history and valuable relationships may receive softer treatment or manual outreach instead of automated escalation, and the team sometimes chooses to wait rather than send a reminder that might damage goodwill. All actions must leave a clear audit trail because statutory requirements and VAT rules demand that every posting be explainable to an auditor and retained for seven years.

The process currently consumes about 720 hours per year across the three-person team. Most of that time goes to boring repetitive matching work on straightforward cases, while the interesting judgment calls on exceptions and customer relationships represent a small fraction of the volume. The team wants to stop spending the week on routine data entry and focus their attention on the cases that actually need human intelligence.

The recommended approach is a hybrid automation that uses AI-powered matching logic to handle routine cases automatically while routing exceptions and relationship-sensitive decisions to human review queues. This recommendation fits the process characteristics and technical constraints better than the alternatives for several specific reasons.

First, the volume and structure of the work strongly favor automation. With 7,200 payment matching events per year and 85 to 90 percent following a standard pattern, there is a large pool of repetitive cases that do not need human intelligence. An AI matching engine can learn to recognize payment reference patterns, handle variations in formatting and punctuation, and confidently match payments to invoices when the data is clean. By scoring each match with a confidence level, the system can auto-post high-confidence matches to the ERP and route the ambiguous 10 to 15 percent to the team for review. This delivers the stated goal of freeing the team from boring work while keeping humans in the loop for the interesting exceptions.

Second, the compliance requirement for auditor-explainable postings makes pure autonomous automation too risky. Statutory audit trails and VAT rules mean every automated posting must be defensible, and the system must capture full provenance of decisions. A hybrid approach satisfies this by logging all automated actions with timestamps, matching scores, and data lineage, and by ensuring that any case requiring judgment goes through a human who takes accountability. This is safer than an autonomous AI agent that might make posting decisions the auditor cannot trace or validate.

Third, the relationship sensitivity of dunning escalation demands human oversight. Good customers with strong payment history should not receive aggressive reminders just because an automated rule fires. The hybrid model automates the three-stage dunning workflow for standard cases but flags good customers or edge cases for manual review before sending escalation emails. This preserves the team's ability to exercise judgment and protect valuable relationships, which is essential in a finance function where customer goodwill has real economic value.

Finally, the technical environment supports this approach. The ERP has an API and the external accountant has integrated with it before, so building a custom integration is feasible. The client has no in-house developer but has budget for external development, which fits the hybrid build model. An external developer can build the matching engine, dunning workflow, and review queue interface in 12 to 16 weeks, and the system can be piloted in parallel with the manual process to tune confidence thresholds and validate audit compliance before going live. The payback period is roughly 16 months, which is reasonable given the build cost and annual savings of around 12,600 EUR.

The three viable automation approaches for this payment matching and dunning process are Hybrid, AI Workflow, and RPA, each scoring 9, 7, and 6 respectively. The Hybrid path combines AI-powered matching with human approval gates, allowing routine cases to flow through automatically while routing exceptions to review queues. This preserves judgment on relationship-sensitive dunning decisions and ensures every automated posting can be explained to auditors, which is essential given the statutory compliance requirements. AI Workflow scores lower because fully autonomous AI matching and dunning, even with confidence scoring, still carries risk of inappropriate escalation without human oversight. The dunning stage decisions in particular require context about customer relationships that an AI cannot reliably infer from transaction data alone, so pure workflow automation would need confidence thresholds and review gates that effectively turn it into a hybrid model anyway.

RPA is viable but less adaptive than AI-based matching. It could automate the standard posting and email sending steps, but the variability in payment references means rule-based RPA logic would require constant maintenance as new patterns emerge. The ERP API reduces the need for brittle UI automation, but RPA still struggles with the judgment calls on ambiguous references and customer escalation. Traditional Code could work with rule-based matching logic, but it would similarly require extensive rule maintenance and would be less adaptive to changing payment reference patterns than an AI matching engine. Both RPA and Traditional Code would still need human exception handling, making them functionally similar to Hybrid but with less intelligent routing of edge cases. The Hybrid approach wins because it automates the 85 to 90 percent standard path, keeps humans accountable for non-routine decisions, satisfies audit trail requirements, and adapts to payment reference variability better than rigid rules.

The recommended implementation starts with integrating to the ERP API and building a data staging layer that normalizes payment references and invoice identifiers. The external accountant has prior integration experience with this ERP, so the technical connection is well understood. The staging layer should clean and standardize payment reference formats, extract invoice numbers using pattern matching or trained extraction models, and prepare structured data for the matching engine. This foundation takes three to four weeks and establishes the audit logging framework that will track every automated action for compliance.

The matching engine is the core intelligence of the system. It should score each incoming bank movement against open invoices using a combination of reference matching, amount alignment, and date proximity. High-confidence matches, where the payment reference exactly matches an invoice number and the amount and timing align, can be auto-posted to the ERP with full audit logging. Low-confidence cases, such as ambiguous references, partial payments, or payments covering multiple invoices, route to a human review queue. The engine can use either AI-based fuzzy matching trained on historical payment data or rule-based logic with confidence scoring, depending on budget and data availability. Training on past payment patterns helps the system learn common reference variations and improves accuracy over time. This phase takes four to five weeks and should be validated against historical data before connecting to live bank feeds.

The dunning workflow automates the three-stage escalation process with configurable timing and email templates. It checks customer payment history in the ERP and flags good customers or those with strong payment records for manual review before sending escalation emails. This preserves relationship judgment and prevents automated dunning from offending valued clients. All dunning actions are logged with timestamps, customer identifiers, and the logic that triggered the escalation, ensuring auditor explainability. The workflow integrates with the email system to send reminders and tracks responses or subsequent payments that resolve the dunning case. This component takes three to four weeks and should be tested with a small cohort of late payers to tune escalation thresholds before full rollout. The final piece is a simple human review interface where the finance team processes the exception queue, approves or corrects flagged matches, and overrides dunning decisions when customer context requires it. All human actions are logged with user IDs and timestamps for compliance, and corrections feed back into the matching engine to improve future accuracy.