Short answer: BNPL providers pay you net of their fee, on a deferred cycle, and deduct refunds from future payouts. If you post a BNPL sale straight to a bank or cash account in Dynamics 365, your cash position is wrong from that moment. The correct pattern posts the gross sale to a dedicated BNPL clearing account, imports the provider’s settlement batch, matches each line to its originating transaction, posts the fee separately, and only then recognizes the bank deposit.

Every article about adding BNPL stops at the checkout. This one covers what happens afterward — which is where finance teams actually feel it.

Why BNPL breaks standard payment posting

Dynamics 365’s default assumption is that a payment means cash, more or less now. BNPL violates that in three specific ways.

Gross sale, net payout. The customer checks out at the full amount. The provider pays you later — weekly or biweekly, depending on the provider — minus a merchant discount fee. The gap between what you invoiced and what lands in the bank isn’t an error; it’s the fee, and it needs its own posting.

Deferred, batched settlement. Payouts arrive as batches covering many transactions, not as one deposit per sale. A single bank line may represent hundreds of orders, several fee deductions, and a few refunds.

Refunds arrive as deductions. A return in March against a January sale typically comes back as a reduction in a future payout rather than a discrete credit. Without linking that adjustment to its original transaction, it shows up as an unexplained shortfall in a later batch.

Post authorizations directly to cash and you get the worst of all three: overstated cash on day one, a phantom shortfall at settlement, and unexplainable variances at month-end.

The clearing-account pattern

The fix is standard practice in payments accounting, and it works cleanly in Dynamics 365.

1. Create a BNPL clearing account per provider. A balance-sheet account (current asset) — one for Klarna, one for Affirm, one for Afterpay, and so on. Separate accounts per provider are worth the extra lines: they let you age what each provider owes you independently.

2. At authorization, post gross to clearing. Debit BNPL Clearing, credit revenue (through your normal sales invoice posting). The bank account is untouched. Tag the transaction with the provider so downstream matching and reporting 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. Anything that doesn’t match gets flagged for review before you post — unmatched lines are the seed of every aging balance nobody can explain later.

4. Post the fee. Debit a payment fee expense account, credit BNPL Clearing, for the fee total in that batch. Posting fees at line level rather than as a batch lump sum is worth the effort: it lets you trace merchant discount cost back to individual transactions, which is the only way to get accurate product-level margin.

5. Recognize the deposit. Debit bank, credit BNPL Clearing, for the net payout — matching the bank statement line exactly.

6. Confirm the clearing account zeroes. Once the batch is fully processed, that batch’s balance in the clearing account should be nil. A residual balance means something didn’t match.

Worked example

A $600 Affirm sale, $18 merchant fee, and a later $150 partial return:

The clawback posts against the clearing account and is netted from a subsequent payout, which is why linking it to the original transaction matters.

Dynamics 365 specifics

Finance & Operations. Use dedicated main accounts for BNPL clearing and payment fee expense, and use financial dimensions to carry the provider and channel so you can report by BNPL provider without proliferating accounts. Settlement imports should create journal entries via a payment or general journal, and bank reconciliation should match the net deposit line to the payout. For multi-entity estates, keep a clearing account per legal entity — see Finance & Operations payments.

Business Central. Set up G/L accounts for BNPL clearing and fee expense, and 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 line. See Business Central payments.

Commerce. In-store and online BNPL both flow through the same clearing logic, but statement posting adds a step: make sure BNPL tenders are distinguished from card tenders in the retail statement so they don’t get lumped into card settlement.

Multi-currency. Use the transaction-date rate for the original sale and the settlement-date rate for the deposit, and post the difference to realized gain/loss. Don’t reuse one rate across both — it silently distorts your fee expense.

Where it usually goes wrong

• Posting to cash at authorization — the root cause of most BNPL reconciliation pain.
• Lump-sum fee posting — cheaper to implement, but destroys transaction-level margin visibility.
• Orphaned clawbacks — return adjustments not linked to their original sale, which age forever in the clearing account.
• Duplicate postings from webhook retries — providers retry failed deliveries as a matter of course. Without a unique provider event ID checked on every inbound event, a network hiccup creates duplicate journal entries that are genuinely painful to unwind.
• One clearing account for all providers — makes it impossible to tell which provider owes you what.

How SensePass automates this

Doing the above by hand across several providers is a monthly grind. SensePass handles the mechanical parts: each provider’s settlement format is parsed by its own adapter, settlement batches are imported and matched to originating transactions, fee and clawback journals are created automatically, and inbound events are de-duplicated so retries don’t double-post.

The practical result for a finance team is a clearing account that ages predictably, fee postings that tie to individual transactions, and a deposit that matches the bank feed without manual adjustment — across Klarna, Affirm, Afterpay, and Zip, Sezzle and Splitit alike, since they all arrive through one connector.

What to test before go-live

• Send the same provider event twice and confirm only one posting is created.
• Import a full settlement file and confirm every line matches to the cent.
• Run a partial refund and confirm the clawback links to the credit note and reduces the clearing balance correctly.
• Test a cross-currency payout and confirm the FX difference posts to realized gain/loss.
• Match a deposit to the bank statement line with no residual.
• Run the first two settlement cycles in parallel — reconcile manually alongside the automated process and compare line by line.

Frequently asked questions

Why can’t I post BNPL payments straight to cash? Because the provider pays later and net of its fee. Posting to cash at authorization overstates your bank balance immediately and creates an unexplained shortfall when the actual deposit arrives.

What account type should the BNPL clearing account be? A current asset on the balance sheet — it represents money the provider owes you between the sale and the payout.

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.

How do BNPL refunds appear in settlement? Usually as deductions from a future payout rather than as separate credits. They must be linked to the originating transaction, or they age in the clearing account as unexplained items.

How do I stop duplicate postings from webhook retries? Key every inbound event on a unique provider event ID and reject repeats. Providers retry routinely, so this isn’t 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; Business Central uses G/L accounts, payment methods, and payment journals.

Can this be automated? Yes. Settlement import, transaction matching, fee and clawback journals, and event de-duplication can all run automatically through a payment connector, leaving finance to handle exceptions rather than data entry.

Get BNPL right on both sides

Offering BNPL is a checkout decision. Keeping it clean is an accounting one — and the second is where the ongoing cost lives. Get the clearing architecture right before you go live, and BNPL becomes just another tender.

Request a demo to see automated BNPL settlement in a Dynamics 365 environment.