If the money is not arriving on time, reconciliation is not the problem: accounts receivable control.
Two tools that get confused
Short answer. Business Central has two distinct mechanisms for working with bank statements, solving different problems. The Payment Reconciliation Journal applies payments to documents: it identifies which invoice was paid and closes the balance. Bank Account Reconciliation compares the bank account balance in the system with the balance at the bank. The first is daily work, the second is a period-end control.
| Payment Reconciliation Journal | Bank Account Reconciliation | |
|---|---|---|
| Question answered | who paid and for what | does our balance match the bank |
| Effect on documents | applies the payment and closes the balance | marks bank entries as reconciled |
| Frequency | daily or weekly | at month end |
| Who runs it | accounts staff | chief accountant / controller |
Both accept the same statement file. The complaint "we imported the statement but the invoices are still open" almost always means the file went into the wrong journal.
File format: why "just import it" rarely works
Out of the box Business Central expects the European standard for bank files — the CAMT family of ISO 20022. Many banks outside that ecosystem, including Ukrainian ones, export their own formats: CSV with a proprietary column set, non-standard XML, sometimes legacy binary formats. There is no direct import.
Three ways out, in ascending order of reliability:
- Reshaping the file by hand into the expected structure. Works for the first few weeks, but it is exactly the routine you were escaping.
- Configuring a Data Exchange Definition. The built-in mechanism: you describe which column holds the date, the amount, the payment reference and the counterparty, and the system reads your bank's format with no development. Once per bank.
- A format conversion extension. Worth it when you deal with several banks or formats change regularly.
In practice the second option covers most companies: one exchange definition per bank, configured during implementation.
How automatic matching works
Once the statement is imported you run the automatic matching action. The system compares every statement line with open documents and proposes a match, scoring its confidence from high down to none.
What it looks at:
- Amount. An exact match scores highest; partial payments are recognised too, with lower confidence.
- Payment reference. An invoice number in the payment text is the strongest signal. This is why document numbering matters:
INV-2026-00147is recognised, "payment as per contract" is not. - Counterparty details. Payer name and bank account are matched against master data.
- Date. Used as a secondary criterion within a tolerance.
High-confidence lines can be accepted in bulk; the rest are handled manually. The real driver of automation here is not the software but discipline in payment references — when customers quote invoice numbers, most receipts apply themselves.
The cheapest improvement available: put the invoice number where the customer sees it first on the printed document, and ask them to quote it in the payment reference. It beats any customization on return per hour spent.
Recurring items with no document behind them
Bank charges, card acquiring fees, interest on balances — statement lines with no invoice attached. Posting them by hand every month makes no sense.
That is what Text-to-Account Mapping is for: you define a fragment of the payment text and the account it should post to. Next time, "monthly account servicing fee" lands on your bank charges account automatically.
One hygiene rule: keep the mapping list short and review it quarterly. A text fragment that is too generic will start capturing the wrong payments.
Does Copilot help?
Recent Business Central versions include a Copilot reconciliation assistant: it proposes matches for lines that did not match automatically and explains why it considers them similar. It runs as a second pass after standard matching — a human still decides.
Our assessment is measured: the assistant removes real drudgery on repetitive payments and helps very little where payment references are filled in carelessly. It amplifies order in your data rather than replacing it.
Common mistakes
- Importing into the wrong journal. The most frequent one. If the goal is closing balances, you need the payment reconciliation journal, not bank account reconciliation.
- Configuring the exchange definition on live data. Do it in a test company, or several failed imports will leave debris in your journals.
- Unstructured document numbers. Automatic matching loses its strongest signal and the hit rate drops sharply.
- Skipping balance reconciliation. A payment journal does not guarantee that your bank balance equals the bank's. That is a separate monthly procedure.
- Over-broad text mappings. A fragment like "payment" will sweep half the statement onto one account.
If you want to size what this automation is worth in your case, run the numbers in our cost calculator or get in touch.
FAQ
Can Business Central import a non-standard bank format without development?
What is the difference between the Payment Reconciliation Journal and Bank Account Reconciliation?
What share of payments matches automatically?
How do you handle bank fees with no invoice behind them?
Do you need a separate module for multiple banks?
Microsoft Dynamics 365 Business Central consultant at NBCS. Explores and documents BC mechanics on a dedicated sandbox.
Still deciding whether the platform fits your business? Start with Business Central platform overview — the problems it solves, what it covers, and how implementation and migration actually run.