The customer pays in four. You get paid once — and that's exactly where the bookkeeping goes sideways.
You turned on Shop Pay Installments in March. Maybe you added Klarna or Afterpay too, because the case studies said pay-later options lift conversion — and yours did tick up. Then month-end arrived, and your bank feed had a new problem: deposits from names you'd never reconciled before, in amounts that matched nothing in Shopify's payout report. Meanwhile your margin came in half a point lower than usual, and nothing on the P&L explains why.
So you lumped the strange deposits into "Shopify income" and moved on. The books tied out — and they were quietly wrong. BNPL accounting is an area where "quietly wrong" compounds every month the mix grows.
Here's the reframe this post is built on: buy-now-pay-later doesn't change when you earn revenue at all. The customer's installment plan is not your problem — it never touches your books. What BNPL actually changes is two things: the fee is bigger, and the money lands in a different stream. Both are fixable in an afternoon once you see them.
BNPL Accounting Rule One: You Get Paid Upfront
Start with the mechanics, because most of the confusion dissolves right here.
When a customer checks out with Shop Pay Installments, Klarna, or Afterpay, three things happen:
- You ship the order like any other sale. The provider approved the customer at checkout; the transaction is done from your side.
- The provider pays you upfront — the full order value, minus their merchant fee. Not in installments. Once.
- The customer pays the provider back over time. Four payments, monthly plans, whatever they picked. If the customer stops paying, that's between them and the provider — you already have your money.
The provider is essentially buying the receivable from you. They take on the customer's credit risk, and they charge you a bigger fee for the privilege — meaningfully more than standard card processing. There's no universal rate; your effective cost depends on your agreement and mix of plan types, so check your own contract. But the direction is consistent: BNPL costs more per order than a card swipe.
The accounting consequence is simpler than most people expect. Revenue is recognized exactly like a card sale — full order value at the point of sale, same as always. There's no deferred revenue, no receivable to age, no installment schedule to mirror in QuickBooks. If someone tells you BNPL means "recognizing revenue as the installments come in," they've confused your books with the provider's.
The Lie: "It's Just Another Payment Method"
That upfront-payment mechanic leads directly to the trap. Since revenue timing is normal, it's tempting to conclude nothing about your bookkeeping needs to change. Toggle on the payment option, watch conversion improve, done.
That's the lie, and it's a generous one — because it's almost true. Two things did change, and both are invisible on the day you flip the switch.
First, the fee got bigger and moved. Your card fees live inside your Shopify Payments payout report — annoying, but at least you know where to look (we mapped every hiding spot in Shopify fees in QuickBooks). Third-party BNPL fees live somewhere else entirely: Klarna's merchant portal, Afterpay's settlement reports. If your fee-tracking habit is "read the Shopify payout report," a chunk of your processing costs just walked out of frame. And if you're not on Shopify Payments, or the BNPL runs as a third-party gateway, Shopify's own third-party transaction fee can stack on top — check your plan.
Second, the money arrives in a new stream. Shop Pay Installments settles through your regular Shopify Payments payouts, so those orders ride along with your card sales. Klarna and Afterpay, running as their own gateways, batch on their own schedules and deposit under their own names. Your bank feed now has two or three settlement streams where there used to be one — each with its own timing, its own fees, and its own report you'd need to open to explain any given deposit.
Neither change announces itself. The first erodes your margin without leaving a line item; the second breaks the deposit-matching routine you've relied on for years. You didn't do anything wrong — the system grew a second set of plumbing while the dashboard looked the same.
A $100 Order, Two Ways
Numbers make this concrete. The figures below are illustrative and fictional — card processing at a typical 2.9% + 30¢, and a made-up flat 6% for the BNPL provider. Your actual agreement will differ; the structure won't.
| Card checkout | BNPL checkout | |
|---|---|---|
| Order total (what the customer sees) | $100.00 | $100.00 |
| Revenue you record | $100.00 | $100.00 |
| Processing fee | $3.20 | $6.00 |
| Cash you receive | $96.80 | $94.00 |
| When you receive it | Next Shopify payout | Upfront — provider's settlement schedule |
| Where the fee is visible | Shopify payout report | Provider's own portal/report |
| Who collects from the customer | You did, at checkout | The provider, over 4+ payments |
Read the revenue row twice: identical. The sale is $100 either way, booked at the point of sale either way. Everything that differs lives below that line — a fee nearly twice the size, arriving through a different pipe, documented in a different report.
That $2.80 gap per order sounds small. It isn't, at mix. More on that below.
Where the Money Lands: One Clearing Account Per Stream
Here's the operational fix for the settlement problem, and it's the same pattern that solves multi-gateway bookkeeping everywhere: every settlement stream gets its own clearing account.
If you've read our payout reconciliation pillar, you know the mechanic — gross sales, refunds, and fees post into a clearing account, the bank deposit transfers out of it, and a zero balance proves everything ties. BNPL doesn't change that method. It multiplies it:
- Shop Pay Installments — no new clearing account needed. SPI settles inside your Shopify Payments payouts, so those orders flow through your existing Shopify Payments Clearing account. The fees are itemized in the payout detail; they're just larger for those orders.
- Klarna — its own clearing account. Klarna's settlements batch on Klarna's schedule and land as Klarna-named deposits. Post the gross sales and fees for Klarna orders there; clear the account when each deposit arrives.
- Afterpay — same again. Own clearing account, own settlement report, own zero-check.
Each account should independently hit zero after every settlement cycle. When one doesn't, you know which stream has the problem before you've opened a single report — which is the entire point of the pattern. WooCommerce stores running Klarna or Afterpay through gateway plugins face the identical structure; the WooCommerce–QuickBooks sync guide walks the platform-specific version.
What you should not do is let all three streams flow into one undifferentiated income account. That's how a Klarna deposit gets booked as revenue (it's net of fees — now your income is understated and your fees are missing) and how a missing Afterpay settlement goes unnoticed for a quarter.
Refunds Through BNPL
Refunds are where BNPL's plumbing shows itself most clearly, so know the flow before your first one.
When you refund a BNPL order, you refund it through the provider — from your side, usually the same refund button as always. The provider unwinds the customer's side: cancels remaining installments, returns whatever the customer already paid. None of that belongs in your books.
What does belong in your books is the same contra-revenue entry as any refund — sales returns up, and the cash clawed back from your next settlement in that stream. The wrinkle is the fee. Whether the provider returns their merchant fee on a refunded order varies by provider and by agreement: some return it in full, some keep a portion, some keep all of it. Don't assume — check your agreement, and when the fee isn't returned, book the kept portion as a processing expense so it doesn't vanish into a reconciliation gap.
Because BNPL refunds cross settlement periods more often than card refunds (the settlement already paid out before the customer changed their mind), they're a common source of clearing accounts that won't zero. The mechanics of getting refund timing right — including cross-period refunds — are covered in depth in our refunds and returns accounting guide.
The P&L Question: What BNPL Does to Blended Margin
Now the strategic part — the reason your margin dipped half a point and nothing on the P&L explained it.
BNPL fees are a processing expense, full stop. Not a marketing cost, not contra-revenue, not a mystery deduction inside a deposit. They belong on their own expense line (or grouped under merchant processing fees), where you can see them move.
And they will move, because they scale with mix. Using the same fictional rates as before, watch what happens to a store doing $50,000 a month as BNPL share grows:
| BNPL share of sales | Card fees (2.9% + 30¢, illustrative) | BNPL fees (6%, illustrative) | Total processing cost | Effective blended rate |
|---|---|---|---|---|
| 0% | ~$1,600 | $0 | ~$1,600 | ~3.2% |
| 20% | ~$1,280 | $600 | ~$1,880 | ~3.8% |
| 40% | ~$960 | $1,200 | ~$2,160 | ~4.3% |
Same revenue. Same products. A full point of margin gone — not lost, spent, on the conversion lift and bigger carts BNPL genuinely delivers. That trade can be worth it. But you can only evaluate it if the fee sits on your P&L as its own line, moving as your mix shifts. Buried in a net deposit, it just looks like your business got mysteriously worse.
The question to put to your own books: if BNPL went from 10% to 30% of your sales next quarter, would your P&L show you the cost? If the answer is no, the fee is being netted somewhere — and the fix is the clearing-account structure above.
איך זה נראה אוטומטי
Everything above is doable by hand: per-stream clearing accounts, gross-revenue journal entries, fees booked from each provider's report, refunds traced across settlement periods. It's the same six-step method from the reconciliation pillar, run once per stream, every cycle. That's precisely the problem — BNPL didn't make the method harder, it made you run it two or three times in parallel, against reports in different portals.
This is the category of work a sync tool exists for. LedgerPort reads orders, refunds, and fees from your store and posts them to QuickBooks with the structure intact — revenue at gross, fees as a visible expense, each settlement stream cleared separately, the same pattern per gateway. Orders post when they reach the payment status you choose, so a BNPL order enters your books when it's captured, not when it's promised — the order sync methods doc shows how that trigger works. Payout journals and fee handling ship on the Scale plan and up; see pricing for where the line sits.
The honest caveat: no tool changes your BNPL economics. The fee is what your agreement says it is. What automation changes is whether that fee is a number on your P&L you can act on — or a residue you discover in April.
The Answer Was Upfront All Along
You came in expecting BNPL to be an installment-tracking problem — some new revenue-recognition regime to learn. It's the opposite. The provider took the installments off your plate entirely and handed you two much more ordinary problems in exchange: a bigger fee in an unfamiliar report, and a new deposit stream in your bank feed.
Both yield to structure. Give each stream a clearing account that must zero. Put BNPL fees on their own expense line and watch the blended rate as your mix shifts. Check your agreement for refund-fee behavior before the first refund, not after.
If your Klarna or Afterpay deposits are currently landing in "Shopify income," that's the thread to pull this week. And if running the clearing-account method across three settlement streams sounds like exactly the kind of month-end you're trying to retire, LedgerPort's free plan is the low-risk way to test the automated version — the $100 worked example above is precisely the translation it does per order, per stream, without the spreadsheet.
