Business Central payment reconciliation for e-commerce: 7 ways to clear open customer entries faster
If you sell online and invoice per order, Business Central holds thousands of open customer ledger entries and your money arrives batched, one Adyen payout covering hundreds of them. This is what that reconciliation actually costs, seven fixes that work, and how Wakakuu went from 55 minutes a day to nine.
If you run this every day, you know the five moments
Why Business Central struggles with e-commerce payments
Business Central applies payments beautifully when a customer pays one invoice with one bank transfer quoting the invoice number. E-commerce does none of those things. An Adyen payout lands as a single net amount covering hundreds of orders, minus fees, minus returns, with a reference that belongs to Adyen rather than to your invoice series. Adyen settles in EUR while the invoice is in SEK. Vipps arrives keyed to something that is not your document number at all.
So the Payment Reconciliation Journal matches a small share automatically, and the rest becomes a spreadsheet. The seven fixes below are what the teams who have solved it do differently. Most of them are decisions, not software.
Stop matching on the reference exactly as it arrives
Almost every failed match in Business Central is a formatting difference, not a missing payment. Your invoice is 12356; the payout file calls it SO12356-1. Normalise references before comparing (strip prefixes, drop the line suffix, pad or trim to length) and a third of your unapplied entries disappear on the first run.
Reconcile against the payout report, not the bank line
The bank statement tells you 1 184 205,00 arrived from Adyen. It cannot tell you which orders that covers. Only the settlement report can. Apply customer entries from the payout report, then tie the report's net total to the bank line as a single check. Two steps, each of which can be right or wrong on its own.
applies the open entries
proves the net arrived
Give fees, returns and FX an account before you start
The gap between gross invoices and net payout is never mysterious: it is fees, chargebacks, refunds and currency. Map each deduction type in each provider's file to a G/L account once, and the difference reconciles itself. Left undecided, it becomes a suspense account nobody wants to open in December.
Decide the write-off threshold once, as a policy
A payment 7,56 short does not deserve a conversation every time it happens. Set a number (under 10,00 in any currency writes off to rounding, above it comes to a person) and put it in writing. Most of the hour disappears here, because most of the hour is one small judgement repeated forty times.
Notice a missing statement day the day it goes missing
CAMT statements are numbered in sequence. When 1021 to 1026 never arrive, nothing breaks, the bank account simply drifts from the ledger and you find out at month end, six days deep. Check the sequence on import and the problem stays a one-minute email to the bank.
Make it impossible to post the same file twice
The single most expensive error in this process is a re-import: every entry applied twice, discovered weeks later, unpicked by hand. Fingerprint each file on the way in and refuse the duplicate outright, naming the journal it already produced. This is a check, not a warning to be clicked through.
Turn every answer into a rule, so it is never asked twice
This is the one that compounds. Every decision a person makes (that this deduction is a fee, that this customer pays at 40 days, that this line type is an internal transfer) should be captured as a rule the moment it is made. A team that does this keeps climbing, because every answer becomes a rule. A team that does not answers the same question every day, forever.
Kvitta is built around this: AI drafts the rules from your own files and explains the ones that failed, the rules do the matching deterministically, and you approve in one sentence.
The part that matters for a Business Central team is where those rules live. Matching logic held inside BC is an extension: changing how a payout is applied means a ticket to your partner, a quote, a slot in their calendar and a retest at the next release wave. Kvitta keeps the rules outside BC, in sentences an accountant reads and edits, so the person who found the answer is the person who applies it, that same day. Your partner keeps the work only they can do.
See how the rules workWakakuu: 55 minutes of Business Central reconciliation, down to nine
Multi-brand e-commerce, six payment sources across two currencies, and one person clearing them every day before anything else could start.
Read Wakakuu's storyWhat this looks like in Business Central
Open items come from BC
Kvitta reads open customer ledger entries directly, or from an export if you would rather not connect anything yet.
Matching happens outside BC
On the free plan nothing is installed. On a connected plan one small Kvitta app, installed once, writes the journals. We publish it and keep it current across release waves. The rules stay in Kvitta, so adding a payment provider changes a rule in Kvitta rather than anything inside Business Central.
A journal in your batch
Balanced to 0,00 and placed in your BANK batch: pasted by you on the free plan, written by Kvitta on a connected plan, and posted in the batches you allow.
Business Central questions
Is this an extension from AppSource?
Kvitta runs outside Business Central. On the free plan nothing is installed and you paste the journal yourself. On a connected plan one small Kvitta app, published by us and installed once, writes the journal into your batch. The rules stay in Kvitta, so a release wave leaves them as they are.
How is this different from the Payment Reconciliation Journal?
The built-in journal matches a bank line to an open entry when the reference and amount line up. It has no view of a PSP settlement report, so batched payouts, fees and currency differences fall to a person. That is the gap Kvitta covers.
Does it post to Business Central automatically?
In the batches you allow. On a connected plan Kvitta writes the journal and posts it wherever Business Central lets it, a setting per batch. On the free plan you paste it yourself.
Is an AI deciding which invoice a payment settles?
No. Matching runs on rules you approved, deterministically. AI drafts those rules from your files, maps the output to your chart of accounts, and talks through the entries that failed. There you can ask what the difference is and turn the answer into the next rule.
We post one revenue journal a month from payout reports. Does this help?
Probably not. Kvitta works against open customer ledger entries. Without receivables per order there is nothing to match, and you would be paying for a step you do not have.
Our payout format is not on your list.
Upload three days of it in a free workspace and send it as a format request. Reading a new format is Kvitta's work. The formats read today are on the providers page.