Bank reconciliation in Dynamics 365 Business Central: where native matching ends

Dynamics 365 Business Central can match payments from a bank statement on its own. For most companies that is enough. This article is about where it stops being enough — and what to do when a pile of unmatched lines stays in your manual queue every day.

What Business Central does natively

Native matching in BC is built on the Bank Account Reconciliation and Payment Reconciliation Journal features. You import a bank statement (via bank API, MT940, CAMT.053, or manual import) and BC tries to match statement lines to open receivables and payables.

The matching logic rests on three things:

• Amount match between a statement line and an open entry.
• Document number or variable symbol in the statement text.
• Payer name and bank account.

On top of that, BC computes a match confidence — High, Medium, Low — and, based on the configured rules, either matches automatically or leaves the line to you. Match tolerance can be set on both amount and date. Statement templates (data exchange definitions) cover common Czech and foreign formats.

When a payer enters a variable symbol or invoice number and pays the exact amount, it works reliably. This is deterministic matching by key — and here the out-of-the-box BC does a good job. If this is your case, you need nothing more.

Where native matching hits limits

The trouble starts when reality does not match the ideal statement. Five situations where native matching in BC is not enough:

1. Missing variable symbol

The payer enters neither a VS nor an invoice number. BC has no key to match on, so only the amount and name remain. When a company has several open invoices for a similar amount, BC does not know which one to pick — and the line ends up in the manual queue. For companies that invoice many small amounts (subscriptions, recurring services), there are dozens of such lines a day.

2. Partial and merged payments

A customer pays only part of an invoice. Or, the other way around, sends one payment for five invoices at once. Native matching looks for a one statement line = one entry match. Splitting one payment across several invoices (or combining several payments into one) is exactly where rule-based logic gets stuck and a person has to untangle it by hand.

3. Enterprise volume

A few dozen lines a day can be clicked through. Thousands of lines a day cannot. At high volume, a "few percent" of unmatched lines turns into a full-time job. And the more you click manually, the more errors arise and the harder they are to trace later.

4. Foreign currencies and exchange-rate differences

The invoice is in EUR, the payment arrives in CZK after the bank's conversion. Because of the rate, the amount on the statement never exactly equals the amount on the invoice. Match tolerance can be stretched, but a wider tolerance means more false matches. With several currencies at once it becomes a fine balancing act that native rules cannot handle well.

5. Custom rules per payer

"This customer always pays late and rounds up." "This branch sends payments under a different company ID." A real company has dozens of such exceptions that a person keeps in their head but BC does not. Native matching has nowhere to store this knowledge, so it repeats it by hand every month.

How to extend it: an AI add-on with an audit log

None of those five situations means you replace BC. It means you extend native matching where it hits limits — through an AL extension wired to a custom matching service.

The principle is simple. BC sends the unmatched statement lines to the service, and the service returns proposals. What passes with high confidence is matched automatically. The rest goes to the manual queue — but not empty: with a proposal and an explanation of why the service thinks this payment belongs to this invoice. The accountant then only confirms, instead of searching.

What such a service does beyond native BC:

• Fuzzy matching without a variable symbol. When the key is missing, we match on a combination of amount, payer name, their payment history, and open entries. Not one character has to line up — the overall picture does.
• Splitting partial and merged payments. The service tries whether one payment corresponds to the sum of several invoices — or whether several payments belong to one.
• Exchange-rate differences. For foreign currencies we account for the conversion and the rate difference within the configured tolerance, not as an exact match.
• Custom rules. Per-payer exceptions are written down once and the service applies them every time on its own.

An important piece that is easy to overlook: an audit log of every step. It is not a black box that "somehow" matches. For each proposal you can see what it was based on, what the confidence was, and who confirmed it. That is the difference between a tool an accountant trusts and a tool that gives them more checking work.

The same principle — idempotence, retry, an audit log of every step, a periodic check that "reality matches" — is what we use wherever the integration must not lose a single entry. On the regulated government system KSeF, we delivered over 40,000 documents this way, with 100% traceability. Payment matching is a milder domain, but the same discipline applies: every automatic step must be provable after the fact.

When to go for it and when not

Let's be honest: if your customers pay with a variable symbol and in a single currency, deterministic matching in BC is enough for you and a custom add-on would be a pointless investment. The box handles this case.

An AI add-on makes sense when at least one of these is true:

• A lot of lines stay in the manual queue every day because the VS is missing.
• You have enterprise volume where manual matching has become a full-time job.
• You work in several currencies with exchange-rate differences.
• You have many per-payer exceptions that native rules cannot capture.

We are not ML researchers and we do not claim AI will match 100% of your lines on its own. The goal is to move the accountant's work from "find where this belongs" to "confirm the proposal" — and to leave what genuinely cannot be matched in the manual queue with a proposal, not on a pile.

What we offer

We implement custom payment matching as a Business Central extension — fuzzy matching without a VS, splitting of partial and merged payments, foreign currencies, custom rules per payer, all with an audit log. Connecting to a bank API and to an ERP is our domain: at one bank we cut contract generation from 2 hours to 3 minutes (40×); on KSeF we delivered over 40,000 documents with 100% traceability.

If a pile of unmatched lines stays in your BC every day, get in touch — we will go through your statement and tell you how much of it can be matched automatically.

FAQ

What does Business Central do natively when matching payments?

BC can import a bank statement and automatically match payments to open entries by amount, date, and the text in the statement. When the statement carries a variable symbol or document number, matching is reliable. Match confidence rules and statement templates cover standard Czech and foreign formats.

When does native matching in Business Central stop being enough?

When the statement has no variable symbol, when partial or merged payments arrive, at high daily line volume, for foreign-currency payments with an exchange-rate difference, or when you need custom rules for a specific payer. In those cases a lot of lines stay in the manual queue.

How do you extend matching in Business Central with an AI add-on?

Through an AL extension wired to a custom matching service. Where the variable symbol is missing, AI/fuzzy matching proposes the most likely open entry by amount, payer name, and history. What passes with high confidence is matched automatically; the rest goes to the manual queue with a proposal. Every step has an audit log.