Automated Payment Matching (Even Without a Variable Symbol)

Matching payments to invoices sounds like a trivial task. A payment lands in the account, you find the invoice it belongs to, you mark it as paid. As long as payments arrive with a clean variable symbol and a matching amount, it really is trivial — off-the-shelf accounting software handles it without any AI.

The problem starts where reality fails to supply a variable symbol. A client pays three invoices in one transfer. Sends a partial payment. Writes an order number into the payment note instead of the VS. Pays in euros for an invoice issued in koruna. And suddenly "mark as paid" turns into an hour of manual detective work every day. This article is about how to automate that work — and where the line is that automation should not cross on its own.

Deterministic matching: variable symbol and exact amount

The base is simple and should stay simple. A payment arrives with a variable symbol that matches the invoice number, and the amount matches to the cent. There is nothing to solve here — the rule is deterministic, the result unambiguous, the match happens automatically and with no assistance.

This covers most payments at companies with disciplined clients and clean processes. If that is your situation, you do not need any AI. Off-the-shelf SaaS will do it for you, and we will tell you so up front. There is no point paying for smart matching when a plain comparison of two numbers is enough.

But the limit of deterministic matching is not whether it works. It is how many payments do not pass through it. And that remainder — often 10 to 30 percent of volume — is where time gets lost and errors creep in.

Where the variable symbol fails

A few payment types are enough for the deterministic rule to stop being sufficient:

• Partial payments. The client pays half the invoice now, the rest next month. The amount does not match, so exact comparison fails — even when the VS is correct.
• Merged payments. One transfer covers three or five invoices at once. There is either just one VS, or none. The system has to recognise that the sum matches a group of invoices, not a single one.
• Missing or wrong VS. The client leaves the VS field empty, or writes a date, an order number, or their own internal code into it. No exact match is found.
• Foreign currency. Invoice in koruna, payment in euros. There is an exchange rate and rounding in between, so the amount never matches exactly. You need tolerance and conversion.
• Rounding and fees. An interbank fee shaves a few koruna off the amount. The payment arrives slightly lower than the invoice.

A deterministic rule would dump each of these into the "unmatched" bucket and send it to the manual desk. This is where fuzzy and AI matching adds value.

What fuzzy and AI matching add

When an exact match fails, the answer is not to give up to manual work. Instead of one rigid rule, you use several signals at once and compute the probability of which invoice the payment belongs to:

• Amount within tolerance — does it match exactly, or after currency conversion and deducting a fee?
• Counterparty name — does the sender's name correspond to the client on the invoice, even when written differently (abbreviation, typo, different legal form)?
• Account number — is it paid from the same account the client used last time?
• Date and due date — does the payment fall within a window around the invoice due date?
• Payment text and note for the recipient — is there an order or invoice number written freely outside the VS field?

Fuzzy matching handles what exact comparison cannot: small typos in the name, a different number format, an invoice number hidden in free text. For merged payments it looks for a combination of invoices whose sum matches the incoming amount. For foreign currency it converts at the rate and compares within tolerance.

The result is not "matched / unmatched". It is a score. When the match is unambiguous and high, matching happens automatically. When it is uncertain or has several candidates, the system does not guess — it prepares a proposal and passes it to a person.

Where the line is: a manual queue with a proposal, not a black box

Here it is important to stay sober. AI matching is not magic that matches absolutely everything. There will always be a remainder of payments where the match is ambiguous — two clients with the same amount, a payment without any trace, an unknown sender.

These payments must not vanish and must not be matched blindly. They go to a manual queue — but not as an empty list to be solved from scratch. For each item the system attaches:

• the most likely candidates (typically two or three),
• a score and the reason it proposes them (amount and account match, but not the VS),
• the option to confirm with one click, or assign manually.

So the accountant is not solving a mystery from zero. They are making a decision: yes / no / this one. The manual work remains but shrinks from an hour to a few minutes — and focuses only on the genuinely disputed cases, not the routine.

And the key point: it is not a black box. Every match — automatic and manual — is written to an audit log. When it happened, by which rule, with what score, who confirmed it if anyone. When an auditor asks half a year later, or a dispute comes up, it is traceable why a specific payment is matched to that particular invoice. For regulated or enterprise accounting this is not a luxury but a requirement.

Reliability: matching is not just matching

Connecting to a banking API and matching numbers is only half the work. The other half is making it survive operation — so no payment is lost, none is matched twice, and you can verify at any time that the state in the system matches reality in the account.

This is the same principle we use for integrations with regulated systems: idempotence (a single payment is not processed twice, even after a restart or a re-downloaded statement), retry on a banking API outage, an audit log of every step, and a periodic "does reality match?" check — does the sum of matched payments correspond to what actually arrived in the account? Without this layer you have matching that looks like it works, right until the API first goes down in the middle of downloading a statement.

We built the same durable logic for an integration with a government e-invoicing system, where over 40,000 documents passed through it with 100% delivery. Payment matching has a different purpose but the same reliability demands.

Where it makes sense to deploy

Let us be concrete about when this pays off and when it does not.

It does not pay off if you have clean variable symbols, low volume, and standard off-the-shelf accounting. There, deterministic matching is enough and AI would be a needless cost.

It does pay off where the box hits its limits:

• high payment volume, where even 15% unmatched means hours of work a day,
• clients who do not supply the VS reliably — merged, partial, foreign-currency payments,
• custom ERP or an integration into a system like Dynamics 365 Business Central, where there is no off-the-shelf matcher,
• a requirement for audit-grade traceability, where you have to be able to evidence every match.

This also includes the follow-on steps: extracting invoices from PDFs via AI extraction with a human in the loop and an audit log (not a black box), automatic posting, and writing back into the ERP. Payment matching is usually one link in a longer chain that makes sense to automate as a whole.

We offer this

We build payment-matching automation and the whole surrounding flow — from downloading the bank statement through invoice extraction and matching to writing into the ERP. We do it where off-the-shelf software is not enough: custom matching logic on top of fuzzy matching, a manual queue with proposals, an audit log, and durable processing that survives production operation.

We are not ML researchers and we do not pretend to be. We are engineers who can connect a bank, an ERP, and matching logic so that it works and is traceable. A real-world example: in one banking workflow we cut contract generation from 2 hours to 3 minutes — fortyfold.

If you handle payment matching by hand and it is starting to hurt, get in touch. We will tell you straight whether the box is enough for you, or whether a custom solution makes sense.

FAQ

Can payments be matched when the variable symbol is missing?

Yes. When the VS is missing or wrong, fuzzy matching uses the amount, counterparty name, account number, date, and payment text. The system proposes the most likely invoice. If the match is unambiguous, it matches automatically; if not, the item goes to a manual queue with a proposal, not into a void.

What happens to a payment the system cannot assign unambiguously?

An unassigned payment does not vanish and is not matched blindly. It goes to a manual queue with a proposal of the most likely candidates and a match score. The accountant only confirms or corrects. Every decision is written to an audit log.

Do I need AI for automated payment matching, or is off-the-shelf software enough?

If you have clean variable symbols and standard accounting, deterministic matching is handled even by off-the-shelf SaaS without AI. AI and fuzzy matching pay off where the box hits its limits — partial and merged payments, foreign currencies, missing VS, custom ERP, and audit-grade traceability at high volume.