Human-centered design systems and product experiences
Core services
01UI/UX Design02Web Development03Software Development042D/3D Experiences05App Development06AI Agents & Automation07Website DesignTechnical services
Frontend Engineering
React DevelopmentNext.js DevelopmentWeb ApplicationsEnterprise DashboardsSaaS PlatformsBackend & Infrastructure
API DevelopmentCloud InfrastructureDevOps & CI/CDBackend SystemsCustom SoftwareIndustries we serve
Technology & Software
AI Payment Reconciliation Agent Development
Payments matched, differences listed
An agent for matching the bank with the books.
An agent for matching the bank with the books. It proposes which invoice each payment settles, explains the reason for every match, handles part payments and bundled transfers, and lists what it could not reconcile for a person to resolve.
Reconciliation is detective work done under time pressure. A customer pays three invoices in one transfer, with a reference that names none of them. Another pays the right amount less bank charges. A third pays an invoice twice. Accounting software matches the easy ones and leaves the rest, and the rest is where month-end goes.
This page describes a workflow we propose to build as a custom project. It does not exist as software yet. It would reuse the exact arithmetic and the proposed-then-approved pattern from our invoice processing demonstration, where a proposal is not an accepted write. Reading bank statements, matching rules and the reconciliation queue are not built.
One Case, Start to Finish
An example of one case, in 6 steps. The same steps play in the picture at the top of this page.
Statement arrives
The morning bank feed brings thirty incoming payments.
Clear matches
Twenty-two match one invoice each by amount and reference.
Batch payment
One transfer equals the sum of three open invoices for the same customer. The combination is proposed.
Small difference
One payment is short by an amount inside your bank-charge tolerance and is proposed with that note.
Exception raised
One payment has no matching invoice and an unknown payer. It goes to the exceptions list.
Approved and posted
The accountant approves the proposals in two groups and resolves the exception by phone.
How the Work Is Done Today
References that say nothing
The transfer is labelled "payment" and nothing else.
One transfer, several invoices
A customer pays a batch and the total matches no single invoice.
Short by the bank fee
The amount is a few units less than the invoice.
Paid twice
A duplicate payment sits unnoticed as an unallocated credit.
Suspense accounts that grow
Unmatched items are parked and never cleared.
Matches nobody can explain
A rule matched it, and no one knows which.
Six jobs it carries through
01Statement intake
Reads bank and payment provider data.
- Bank feeds and statement files
- Card and payment provider payouts
- Each line with its reference
- Duplicated lines detected
02Match proposals
Proposes what each payment settles.
- Exact amount and reference first
- Combinations of open invoices
- Customer and payment history
- A confidence note with the reason
03Difference handling
Deals with amounts that are close.
- Bank charges within your tolerance
- Discounts your terms allow
- Currency differences by your rule
- Anything else left for a person
04Exceptions list
Lists what does not reconcile.
- Payments with no matching invoice
- Overpayments and duplicates
- Underpayments beyond tolerance
- Unknown payers
05Review and posting
Lets finance approve the matches.
- Certain matches grouped for quick approval
- Uncertain ones shown with alternatives
- Posted to the ledger after approval
- A trail of who approved what
06Period-end support
Helps close the period.
- What is still unreconciled and why
- Ageing of unmatched items
- Evidence for the auditor
- Patterns worth a new rule
What We Need to Scope This
- The process as it runs today, in a few lines.
- The systems it touches, for example bank data, accounting, customers, rules.
- Rough monthly volume, and who approves what.
Every Match Has a Reason, and a Person Approves the Posting
The agent proposes, and each proposal says why: amount, reference, combination or history. Finance approves before anything is posted, and can choose to let exact matches through automatically. Tolerances for bank charges and discounts are your rules, applied where anyone can see them.
It has read access to bank data and cannot move money. What it cannot match stays on a visible list until a person resolves it.
- A stated reason for every match
- Posting after approval
- Tolerances set by you
- Unmatched items stay visible
- Read access to bank data
- A trail for the auditor
What It Reads and Writes
The systems named here are the kind this agent works with. Which ones it connects to in your case is settled in the scope.
Bank data
- Bank feeds
- statement files
- payment provider reports
Accounting
- Your ledger and open items
Customers
- Payment history and remittance advices
Rules
- Tolerances and matching rules
Review
- The accountant who approves
Audit
- The trail kept for each match
What Buyers Ask First
Our accounting software already matches payments. What does this add?
Built-in matching handles exact amounts with clear references. This agent works on what is left: batch payments, short payments, missing references and duplicates. It explains each proposal and keeps an exceptions list with reasons.
How is this different from the receivables reminder agent?
Reminders chase invoices that are unpaid. Reconciliation establishes which invoices are unpaid in the first place, by matching what arrived. Running reminders on unreconciled books means chasing customers who already paid.
Can it post matches without anyone checking?
Only if you decide so, and typically only for exact matches on amount and reference. Everything involving a tolerance, a combination or a judgement is proposed and waits for approval.
What exists today?
Not as software yet. This page describes a proposed workflow. It would reuse the exact arithmetic and the proposed-then-approved pattern from our invoice processing demonstration, where a proposal is not an accepted write. Reading bank statements, matching rules and the reconciliation queue are not built. A project starts by mapping your process, then proving the first steps on test data before anything touches a live system.
Bring Last Month's Unmatched Items
The ones that took longest to clear. We will show how each would have been proposed, and which genuinely needed a person.