In practice, ask a Dynamics 365 finance team what consumes their month-end, and payments come up quickly. Not the payments themselves, which usually work fine. The problem is what happens afterwards, when a deposit lands in the bank and nobody can immediately say which transactions it represents.
Notably, this ranks among the most common complaints in ERP finance. Yet it is rarely a software fault. Instead, it comes from a mismatch between how ERPs expect money to behave and how payments actually settle.
So here is what breaks, why, and the posting pattern that fixes most of it.
The core mismatch
First, Dynamics 365 assumes something reasonable. A payment means money, more or less now, for the amount on the invoice.
But payments do not work that way. For example, a customer pays $1,000. Your processor takes its fee. Four days later a deposit arrives for $12,847.33, covering 38 transactions from three different days, minus fees, minus two refunds from last month.
Consequently nothing matches anything. The invoice says $1,000, the bank says $12,847.33, and somebody has to bridge the two by hand.
The seven ways it breaks
1. Gross sale, net payout. You invoice the full amount, but the processor pays you less its fee. Post the sale straight to a bank account and your cash is overstated from the moment of sale. Meanwhile the fee never gets recorded as an expense at all.
2. Batched deposits. Second, processors settle in batches. Therefore one bank line represents many transactions, and matching it means decomposing the batch rather than finding a single counterpart.
3. Timing gaps. Third, card authorisation is instant while settlement is not. Alternative methods are worse. Buy-now-pay-later providers pay on their own deferred cycle, and cash voucher methods such as OXXO or Boleto confirm days after checkout. So the sale and the money live in different periods.
4. Refunds arriving as deductions. A March return against a January sale usually appears as a reduction in a future payout, not a discrete credit. Unless it is linked to the originating transaction, it shows up as an unexplained shortfall in a later batch.
5. Multi-currency drift. Meanwhile the sale converts at one rate and the payout at another. Without explicit handling, that difference either distorts your fee expense or sits as an unexplained variance.
6. Duplicate postings. Also, payment providers retry webhook deliveries routinely rather than exceptionally. Without de-duplication on a unique event ID, a network hiccup creates a second journal entry that is genuinely painful to unwind.
7. Multiple channels and processors. Finally, online, in-store and invoice payments frequently run through different systems. Each one settles differently, so finance ends up reconciling three feeds rather than one ledger.
In practice, most teams recognise several of these. The good news is that one architectural pattern addresses nearly all of them.
The fix: clearing accounts
This is standard practice in payments accounting, and it also works cleanly in Dynamics 365. The principle is simple: never post a payment directly to bank at the moment of sale.
Instead:
1. Create a clearing account per provider. First, a balance-sheet current asset. One for each processor or payment provider you use. Separate accounts matter, because they let you age what each provider owes you independently.
2. At authorisation, post gross to clearing. Debit the clearing account, credit revenue through your normal invoice posting. The bank account stays untouched. Tag the transaction with the provider so downstream matching can filter on it.
3. When the settlement batch arrives, match it. Import the provider's settlement report and match each line back to its originating sales order or invoice. Flag anything that does not match before posting — unmatched lines are the seed of every aging balance nobody can explain later.
4. Post the fee separately. Then debit payment fee expense and credit clearing, for the fees in that batch. Do this at line level rather than as a batch lump sum. It costs a little more effort and it is the only way to get accurate cost per transaction, which you need for any serious cost analysis.
5. Recognise the deposit. Next, debit bank and credit clearing, for the net payout — matching the bank statement line exactly.
6. Confirm the batch zeroes out. Finally, once processed, that batch's balance in the clearing account should be nil. A residual means something did not match, and you want to know now rather than at year end.
A worked example
A $600 sale, $18 processing fee, and a later $150 partial refund:
| Event | Debit | Credit |
|---|---|---|
| Authorisation | Clearing $600 | Revenue $600 |
| Settlement — fee | Fee expense $18 | Clearing $18 |
| Settlement — deposit | Bank $582 | Clearing $582 |
| Refund clawback | Clearing $150 | Revenue / AR $150 |
So the clawback posts against clearing and nets from a later payout. That is exactly why linking it to the original transaction matters.
How this looks in each module
Finance & Operations. Use dedicated main accounts for clearing and fee expense, and use financial dimensions to carry the provider and channel. That way you report by provider without proliferating accounts. Settlement imports should create entries through payment or general journals, and bank reconciliation should match the net deposit line. For groups, keep a clearing account per legal entity — see .
Business Central. Meanwhile, set up G/L accounts for clearing and fee expense, plus a payment method per provider so customer ledger entries carry the tender. Use payment journals for settlement postings, and the bank account reconciliation for the payout. More at .
Commerce. In-store and online flow through the same clearing logic. However, statement posting adds a step: make sure alternative tenders are distinguished from card tenders in the retail statement, so they are not lumped into card settlement. See .
Is your reconciliation actually broken? A quick diagnostic
So answer these honestly. Any “no” indicates work to do.
- Can you explain every balance in your payment clearing accounts today?
- Do processing fees post as their own expense line, at transaction level?
- Do refund clawbacks link to their originating sale?
- Does your bank reconciliation match statement lines without manual adjustment?
- Would a duplicated provider webhook create a second journal entry?
- Can you report cost per transaction by channel and by provider?
- Does month-end close without a payments-related workaround?
In practice, most teams fail three or four. That is normal, and each one is fixable independently.
What to automate
However, manual reconciliation scales badly. Every payment method you add multiplies the work, which is why merchants who expand into alternative methods often discover the finance cost afterwards.
Fortunately, the mechanical parts automate well: importing settlement files in each provider's format, matching lines to originating transactions, creating fee and clawback journals, and de-duplicating inbound events so retries never double-post.
Where payments run through a rather than several separate integrations, this happens once rather than per provider. posts transactions back into Dynamics 365 automatically across cards, wallets, , bank rails and , so finance works from one ledger regardless of how many methods the business accepts.
That matters most for teams under collection pressure, where reconciliation delay directly slows .
What to test before you trust it
So whether you automate or not, verify these specifically:
- Send the same provider event twice, and confirm only one posting results
- Import a full settlement file and confirm every line matches to the cent
- Run a partial refund and confirm the clawback reduces clearing correctly
- Test a cross-currency payout and confirm FX difference posts to realised gain or loss
- Match a deposit to a bank statement line with no residual
- Run two settlement cycles in parallel with your manual process, then compare line by line
Notably, the parallel run is the one people skip. It is also the one that catches problems before they reach the ledger.
Frequently asked questions
Why don't payments match my bank deposits in Dynamics 365? Because processors pay net of fees, in batches, on a delay, with refunds deducted from later payouts. So a single deposit rarely corresponds to a single transaction.
What is a payment clearing account? A balance-sheet current asset representing money the provider owes you between the sale and the payout. It bridges the timing and amount gap between the two.
Should I use one clearing account or one per provider? One per provider. It lets you age each provider's balance independently and makes mismatches far easier to trace.
Why post fees separately instead of netting them? Because netting hides your true cost per transaction, which you need for margin analysis and for comparing processors.
How do refunds appear in settlement? Usually as deductions from a future payout rather than separate credits. They must link to the originating transaction, or they age as unexplained items.
How do I prevent duplicate journal entries? Key every inbound provider event on a unique event ID and reject repeats. Providers retry routinely, so this is not an edge case.
Does this differ between Business Central and Finance & Operations? The accounting pattern is identical. The mechanics differ — F&O uses main accounts with financial dimensions and journals, while Business Central uses G/L accounts, payment methods and payment journals.
SensePass is a payment gateway and connector for Microsoft Dynamics 365. It links Business Central, Finance & Operations and Commerce to 112 payment methods and 50+ processors through a single integration, with settlement matching, fee posting and reconciliation automated back into the ERP. or .