Finance

Bank statements in Business Central: import and automatic reconciliation

Applying payments by hand is the most visible routine in any finance team. Business Central handles it with two tools — and confusing them is the costliest mistake.

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 JournalBank Account Reconciliation
Question answeredwho paid and for whatdoes our balance match the bank
Effect on documentsapplies the payment and closes the balancemarks bank entries as reconciled
Frequencydaily or weeklyat month end
Who runs itaccounts staffchief 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:

  1. Reshaping the file by hand into the expected structure. Works for the first few weeks, but it is exactly the routine you were escaping.
  2. 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.
  3. 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-00147 is 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

  1. 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.
  2. Configuring the exchange definition on live data. Do it in a test company, or several failed imports will leave debris in your journals.
  3. Unstructured document numbers. Automatic matching loses its strongest signal and the hit rate drops sharply.
  4. Skipping balance reconciliation. A payment journal does not guarantee that your bank balance equals the bank's. That is a separate monthly procedure.
  5. 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?
Yes, through the built-in Data Exchange Definition: you describe your bank file structure once — date, amount, payment reference, counterparty details — and imports work from then on without programming. Development is only needed for unusual formats or complex transformation logic.
What is the difference between the Payment Reconciliation Journal and Bank Account Reconciliation?
The first applies payments to documents and closes customer and vendor balances. The second compares the bank account balance in the system with the balance at the bank and is a period-end control procedure.
What share of payments matches automatically?
That depends on data quality rather than the software. When counterparties quote invoice numbers in the payment reference, most receipts match automatically. When references are free text, automation helps considerably less.
How do you handle bank fees with no invoice behind them?
Through Text-to-Account Mapping: define a fragment of the payment text and the account it posts to. The system then handles those lines on its own.
Do you need a separate module for multiple banks?
No. Each bank account is a separate card with its own import setup. A dedicated solution only makes sense when you have many banks and formats change often.
N
Автор NBCS

Microsoft Dynamics 365 Business Central consultant at NBCS. Explores and documents BC mechanics on a dedicated sandbox.

← All articles

Read next

Ready to modernize your business?

Leave your details and we'll send the details of a free process audit. We reply within one business day.

or write directly: nbcs365@zohomail.eu · +380 98 107 5878