How do I record income if customers pay via Klarna or similar services?

Understanding what Klarna (and similar services) actually do

When a customer chooses Klarna, Clearpay/Afterpay, Affirm, PayPal Pay in 3, or another “buy now, pay later” (BNPL) option at checkout, it can feel like the customer is paying you in instalments. From your business’s perspective, though, the most important question is: who is paying you, and when?

Most BNPL providers sit between you and the customer. The customer agrees to pay the BNPL provider over time, while the BNPL provider (or its payment partner) pays you—often quickly and usually less a fee. That fee is the “cost of getting paid” in exchange for offering instalments to customers. This structure means your accounting is typically not “instalment income”; it’s usually a sale to the customer, settled by a third-party payment service, net of fees, and sometimes with reserves or delayed settlement.

However, BNPL arrangements are not all identical. Some providers pay you upfront (minus fees), some pay you after a short delay, and some may allow you to carry part of the risk or hold back a portion as a reserve. The correct bookkeeping approach depends on the contract terms and your accounting basis (cash vs accrual). The good news is that you can handle most Klarna-like flows cleanly with a few consistent rules.

Start with the two fundamental questions: cash vs accrual

Before picking journal entries, you need to know which accounting basis you use for your financial statements and tax reporting:

Accrual basis: You record revenue when it is earned (when you deliver the goods/services and the customer is obligated to pay), not necessarily when cash hits your bank. Payment timing affects accounts receivable and clearing accounts, not revenue recognition.

Cash basis: You record revenue when you receive cash (or when it is considered received under your local rules). Timing is closer to bank deposits, but you still need to separate gross sales from fees and reconcile reports.

Many small businesses use cash basis for simplicity, while larger businesses, inventory-heavy operations, or those needing GAAP/IFRS style statements use accrual. BNPL doesn’t change those foundations—it just adds an intermediary and a fee.

Think in “gross sale” terms, not “net deposit” terms

A common error is to book the net amount deposited by Klarna as “sales.” That makes your revenue too low and hides payment fees inside revenue. Instead, record the sale at the full selling price (gross), then record any BNPL/processing fees as an expense (or as a contra-revenue, depending on your reporting preference and materiality).

For example, if a customer buys a £100 item and the BNPL provider deposits £96 after £4 fees, the correct economic story is still: you made a £100 sale and paid £4 to accept BNPL as a payment method.

Recording gross sales also makes your reporting consistent across payment methods. A £100 card sale and a £100 BNPL sale should both be £100 revenue, with payment fees listed separately so you can measure margin and payment costs clearly.

A simple mental model: the “clearing account” approach

BNPL providers typically generate multiple numbers: the order total, refunds, disputes/chargebacks, fees, and the final payout. If you post directly to your bank account each time money lands, you’ll struggle to match orders to payouts. A clearing account makes this much easier.

A clearing account (sometimes called “Klarna Clearing,” “Payment Processor Clearing,” or “Undeposited Funds”) is an intermediate asset account where you temporarily park the amount owed to you by the payment service. Then, when payouts arrive in your bank, you clear them against that account. This structure keeps sales recognition tied to orders, not tied to payout timing.

This approach works very well under accrual accounting and can also help under cash basis when you want clean reconciliation. Many accounting systems and ecommerce integrations use exactly this logic behind the scenes.

Common scenario 1: BNPL provider pays you promptly, net of fees

This is the most typical setup for Klarna-like services. You make a sale today; the provider pays you in a day or two; they deduct their fee from the payout.

Accrual basis entries (typical ecommerce goods sale)

At the time of sale (or shipment/fulfillment if that is your revenue trigger):

Debit: Klarna/BNPL Clearing (asset) … £100

Credit: Sales Revenue … £100

If you track cost of goods sold (COGS) and inventory, you also record the inventory movement (at your cost):

Debit: Cost of Goods Sold … (your cost)

Credit: Inventory … (your cost)

When you receive the payout of £96 and the fee is £4:

Debit: Bank … £96

Debit: Payment Fees Expense … £4

Credit: Klarna/BNPL Clearing … £100

Net result: revenue is correctly stated at £100, fees are visible as an expense, and the clearing account returns to zero once reconciled.

Cash basis entries (if you record revenue when paid)

Under cash basis, you might record revenue at payout time. But you still want gross sales and separate fees:

When payout arrives:

Debit: Bank … £96

Debit: Payment Fees Expense … £4

Credit: Sales Revenue … £100

If you use a clearing account even on cash basis, you can still post sales from order reports into clearing, then clear out on payout; just ensure your tax logic aligns with cash basis requirements. Some businesses keep it simpler by booking revenue only on payout, but still using the gross/fee split.

Common scenario 2: BNPL provider pays you upfront, but holds a reserve

Some payment arrangements include a reserve or rolling holdback—an amount withheld to cover potential refunds, disputes, or risk exposure. You might see a deposit that’s less than “gross minus fee,” with the remainder paid later.

Example: £100 sale, £4 fee, £10 reserve held back, £86 paid now, £10 paid later.

At sale time (accrual basis):

Debit: BNPL Clearing … £100

Credit: Sales Revenue … £100

At first payout:

Debit: Bank … £86

Debit: Payment Fees Expense … £4

Debit: Reserve Receivable (asset) … £10

Credit: BNPL Clearing … £100

Later, when the reserve is released:

Debit: Bank … £10

Credit: Reserve Receivable … £10

This keeps your revenue and fee recognition clean while acknowledging that you still have an asset (the reserve) that should turn into cash later.

Common scenario 3: The customer returns goods and you issue a refund

Refunds are where BNPL can get confusing because money might flow differently than card refunds. Sometimes the provider refunds the customer and then deducts the refund from your next payout, rather than sending money back from your bank.

The accounting principle is: refunds reduce revenue (or increase a returns/allowances account), and you reverse the tax and COGS effects appropriately. The cash mechanics are handled through clearing accounts.

Accrual basis refund example using clearing

Original sale: £100 revenue posted to BNPL clearing. Now you refund £100.

At the time the refund is initiated/approved:

Debit: Sales Returns and Allowances (contra-revenue) … £100

Credit: BNPL Clearing … £100

If you track inventory, and you receive the item back into stock:

Debit: Inventory … (your cost)

Credit: Cost of Goods Sold … (your cost)

Then, when the provider nets the refund against a future payout, your clearing account structure naturally absorbs it. If the provider deducts £100 from a future payout, your bank deposit will be £100 lower than expected, and the clearing balance will reflect that. If instead money is taken from your bank directly, you would post:

Debit: BNPL Clearing … £100

Credit: Bank … £100

That entry clears the liability/negative balance created by the refund posting. The exact sequence depends on how the provider settles, but the end state should be: revenue reduced and cash reduced (or future cash reduced) with clearing reconciled to statements.

Handling partial refunds

Partial refunds work the same way: reduce revenue for the refunded portion, and then clear the settlement. You may need to split between item value and shipping if your reports do, and you might need to reverse tax proportionately.

Common scenario 4: BNPL disputes, chargebacks, and adjustments

Disputes can show up as deductions from payouts, separate “chargeback” debits, or withheld funds. The accounting treatment depends on whether you consider the amount likely to be recovered.

A practical approach is to use a dedicated account such as Dispute Expense or Chargeback Loss and a Disputes Receivable if you contest the dispute and expect recovery.

If a dispute is deducted and you do not expect to win it:

Debit: Chargeback Loss … £X

Credit: BNPL Clearing … £X

If you expect to recover it and you’re actively contesting:

Debit: Disputes Receivable … £X

Credit: BNPL Clearing … £X

Then, if you later lose:

Debit: Chargeback Loss … £X

Credit: Disputes Receivable … £X

If you win and the provider repays you:

Debit: Bank … £X

Credit: Disputes Receivable … £X

This keeps your clearing reconciliations tidy and avoids “mystery” differences between order totals and deposits.

VAT/sales tax considerations when BNPL is used

Taxes are often where people worry that instalments change the timing. In most retail-style BNPL arrangements, from the merchant’s perspective, nothing about the taxable sale changes just because the customer pays the BNPL provider over time. You are still making a taxable sale to the customer on the sale date (or shipment date), and you must account for VAT or sales tax accordingly.

What can change is how your platform reports tax, how refunds reverse tax, and how fees are treated. BNPL fees are usually a cost of payment acceptance and typically do not change the tax collected from the customer on the sale. You generally record fees as expenses and record tax based on your invoicing/checkout totals.

Practical steps to avoid tax confusion:

Make sure your revenue entry is based on the order total before fees and includes the correct tax split (net sales vs tax liability).

Ensure refunds reverse tax in the same proportion and map to the same tax liability accounts.

Do not treat the BNPL fee as a reduction of taxable sales unless your local rules and reporting specifically require it. Most businesses keep it separate as an expense, which also makes tax reporting simpler.

If you operate in multiple jurisdictions, the tax decision points are typically about where the sale is deemed to occur, what rate applies, and how returns are handled—BNPL is usually just a payment method layered on top.

Revenue recognition for services and subscriptions paid via BNPL

If you sell services, digital access, or subscriptions, the big question is: when is revenue earned? BNPL doesn’t override that. Under accrual accounting, you still recognize revenue as you deliver the service.

For a one-time service delivered immediately, you can recognize revenue at the time you perform the service, just as with a card payment.

For services delivered over time (for example, a 12-week course, a yearly membership, or an ongoing service contract), you may need to defer revenue and recognize it over the service period. In that case, the BNPL provider’s payment is simply settlement of a receivable, not immediate revenue.

Example: course sold for £600, delivered over 3 months

At sale time, if you collect payment upfront via BNPL but must deliver over time, you may record:

Debit: BNPL Clearing … £600

Credit: Deferred Revenue … £600

As you deliver the course (monthly recognition of £200):

Debit: Deferred Revenue … £200

Credit: Service Revenue … £200

When payout arrives, you clear the BNPL clearing against bank and fees as usual:

Debit: Bank … (net)

Debit: Fees Expense … (fees)

Credit: BNPL Clearing … £600

This properly separates cash settlement from revenue recognition.

Are BNPL fees “merchant fees” or “discounts”?

In everyday bookkeeping, it’s perfectly acceptable to classify BNPL costs as “Merchant Fees,” “Payment Processing Fees,” or “Selling Expenses.” Some businesses choose to treat them as a contra-revenue (reducing revenue rather than increasing expenses). Either approach can be acceptable depending on your reporting framework and materiality, but consistency matters.

Why most small and mid-sized businesses prefer an expense account:

It preserves a clear, comparable “gross sales” number across all payment methods.

It makes it easy to analyze payment costs as a percentage of sales.

It avoids understating revenue, which can affect lender reporting, investor metrics, or internal KPIs.

If you do use contra-revenue, be sure you apply it consistently across similar payment costs, or you can end up with confusing comparisons.

How to record income when BNPL pays you in multiple payouts

Sometimes one day’s orders are paid out across several settlements, or one payout covers multiple days. This is normal, and it’s another reason a clearing account is so useful.

The workflow looks like this:

Record each day’s orders (or each order batch) to BNPL clearing at the gross amount.

When the provider pays out, record the bank deposit and the fees, and credit the clearing account for the gross payout amount represented.

Reconcile the clearing account to the provider’s payout statement so the balance returns to zero (or to an expected reserve/withheld amount).

If your bookkeeping system supports it, attach the payout statement to the reconciliation so future you (or your accountant) can audit the logic quickly.

What if you do not want a clearing account?

You can book directly to bank, but you will almost always end up with reconciliation pain, especially with refunds and mixed payouts. If you insist on skipping clearing, your minimum best practice is:

Record revenue gross and fees separately whenever you post a deposit.

Create a consistent method to handle refunds and chargebacks so you don’t accidentally double-count them.

Regularly reconcile provider reports to your ledger, not just your bank feed.

In practice, most businesses that scale beyond a small volume find a clearing account saves hours each month.

Practical chart of accounts setup for Klarna-like payments

You don’t need a complex chart of accounts, but you do need a few intentional buckets. A sensible setup might include:

Assets:

Bank

Accounts Receivable (if you invoice)

BNPL Clearing (e.g., “Klarna Clearing”)

Disputes Receivable (optional)

Reserve Receivable (optional)

Liabilities:

Sales Tax/VAT Payable

Deferred Revenue (if you have subscriptions or prepayments)

Income:

Sales Revenue (or split by product lines)

Shipping Income (if applicable)

Contra-income (optional):

Sales Returns and Allowances

Expenses:

Payment Processing Fees (or “Merchant Fees”)

Chargeback Loss (optional)

This structure gives you clean reporting while keeping bookkeeping manageable.

Matching orders to payouts: the reconciliation workflow that actually works

To record income correctly, you need to reconcile three data sources:

1) Your ecommerce platform or POS order report (gross sales, tax, shipping, discounts, refunds).

2) The BNPL provider’s settlement/payout report (payouts, fees, adjustments, reserves, refunds, disputes).

3) Your bank statement (actual deposits and withdrawals).

A clean monthly workflow is:

Step 1: Post sales from the order system into your accounting ledger (daily, weekly, or via integration). Map BNPL tenders to BNPL clearing, not directly to bank.

Step 2: Import or enter payouts based on the provider’s settlement report. Post: bank (debit), fees (debit), clearing (credit).

Step 3: Reconcile your bank deposits to recorded payouts.

Step 4: Reconcile the BNPL clearing account to the settlement report totals. Any remaining balance should be explainable (for example: end-of-month timing differences, withheld reserves, pending refunds, or unresolved disputes).

Do this consistently and you’ll avoid the end-of-year panic where revenue is off and nobody can trace why.

Common pitfalls (and how to avoid them)

Pitfall 1: Recording net deposits as income

This understates revenue and hides fees. Fix it by recording gross sales and booking fees separately.

Pitfall 2: Double-counting refunds

If you record a refund in your ecommerce platform and then also record the settlement deduction as an expense, you might count it twice. The clearing account method prevents this because refunds post to clearing and then settle naturally through payouts.

Pitfall 3: Ignoring timing differences

End-of-month sales often pay out in the next month. Under accrual basis this is normal; under cash basis it can shift taxable income. Make sure you understand which basis you’re using and reconcile accordingly.

Pitfall 4: Misclassifying reserves

Reserves are not fees. They are amounts still owed to you (an asset) unless your contract says they are forfeited or applied permanently. Track them separately if material.

Pitfall 5: Not separating BNPL from other tender types

If you lump all payment methods together, it becomes harder to audit fees and payout issues. Separate tender types in reporting and in your clearing accounts (or at least via classes/tags).

How this looks in real life for ecommerce stores

Consider a week of transactions where you have multiple payment methods:

Card and wallet payments may settle daily via one processor.

BNPL payments may settle in batches with different fee structures.

Refunds may hit as deductions in later settlements.

If you record every deposit as “sales,” your ledger becomes a blur of mismatched amounts. If you instead record every order as a sale and every settlement as a clearing event, everything lines up: orders reconcile to tender types, and tender types reconcile to payouts.

This is especially important when you start running promotions. Discounts reduce sales at the order level; fees reduce profit at the payment level. Keeping those separate allows you to answer basic questions like: “Are our promotions working?” and “Is BNPL costing us more than card?” without guesswork.

How this looks for service businesses and invoices

Some service businesses use BNPL as a way to let customers finance invoices. The mechanics can vary:

The BNPL provider might pay you when the customer signs up, making the provider the source of funds.

Or the provider might pay you as the customer pays them (less common for mainstream BNPL at checkout, but possible in financing arrangements).

For invoiced services, you’ll often have an accounts receivable balance originally due from the customer. When the customer chooses BNPL financing and the provider pays you, you effectively settle the customer receivable and replace it with cash (and fees).

A common accrual flow for an invoice that later gets financed:

At invoice issuance (if you recognize revenue then):

Debit: Accounts Receivable … £1,000

Credit: Service Revenue … £1,000

When BNPL provider settles (say £960 net after £40 fee):

Debit: Bank … £960

Debit: Payment Fees Expense … £40

Credit: Accounts Receivable … £1,000

This keeps customer receivables accurate and shows the cost of financing acceptance.

What to do if the BNPL provider collects in instalments and pays you instalments

While many BNPL models pay merchants quickly, some financing structures can result in staged payouts. If you truly receive multiple merchant payments tied to the customer’s instalments, you still do not necessarily recognize revenue in instalments (especially under accrual). You recognize revenue based on delivery; you record a receivable from the BNPL provider (or customer) for the full amount and then reduce that receivable as cash arrives.

Example: £1,200 product delivered today; provider pays £400 now and £400 in each of the next two months, with total fees of £60 spread out.

At sale (accrual):

Debit: BNPL Receivable (or Clearing) … £1,200

Credit: Sales Revenue … £1,200

As each instalment arrives, allocate the portion of fees as reported and reduce the receivable. If fees are deducted upfront, record them then; if deducted each month, record them each month. The key is: revenue is not driven by cash timing; it’s driven by performance/delivery.

Should you treat BNPL as “factoring” or “loan”?

In most straightforward merchant BNPL setups, you are not taking out a loan. You are selling goods/services and accepting a payment method that results in a fee. The BNPL provider is effectively purchasing or settling the customer’s obligation. The provider assumes credit risk on the consumer side (subject to contract terms), and you pay a merchant discount fee for the service.

You typically do not record a liability like a loan payable because you have not borrowed money—you have received payment for a sale. Your obligation is to deliver the goods and to honour refunds/returns, not to repay the BNPL provider as a borrower. That said, always be alert for unusual contract terms that require you to reimburse defaulted consumer payments beyond standard dispute/chargeback exposure. If that’s part of your agreement, you may need more nuanced accounting treatment for risk reserves.

How to document your policy so it stays consistent

Even if you’re a small business, it helps to write a short internal policy that answers:

When do we recognize revenue (order date, shipment date, service delivery date)?

Do we use a payment clearing account for Klarna and other processors?

Where do we book BNPL fees (merchant fees expense vs contra-revenue)?

How do we record refunds and disputes?

How often do we reconcile (weekly, monthly)?

This “mini policy” reduces errors when staff change, when you add new payment methods, or when you hand books to an accountant at year-end.

A detailed end-to-end example you can follow

Let’s walk through a simplified month with BNPL, using accrual basis and a clearing account.

Transactions:

Sale #1: £120 gross (includes £20 VAT), BNPL fee £4.80, payout is £115.20 net.

Sale #2: £60 gross (includes £10 VAT), BNPL fee £2.40, payout net £57.60.

Refund: £60 gross refunded for Sale #2, processed as a deduction from the next payout.

Assume fees are withheld at payout time and the provider’s statement shows fee deductions and the refund deduction.

Step A: Record sales at order/shipment time

Sale #1: Post net sales and VAT liability. If the gross is £120 with £20 VAT, net sales are £100.

Debit: BNPL Clearing … £120

Credit: Sales Revenue … £100

Credit: VAT Payable … £20

Sale #2: Gross £60 with £10 VAT, net sales £50.

Debit: BNPL Clearing … £60

Credit: Sales Revenue … £50

Credit: VAT Payable … £10

Step B: Record refund when approved

Refund for Sale #2:

Debit: Sales Returns and Allowances … £50

Debit: VAT Payable … £10

Credit: BNPL Clearing … £60

Now the customer’s economic effect is reversed and the clearing account reflects that the provider will net it out in settlements.

Step C: Record payouts and fees

Payout for Sale #1 (net £115.20, fee £4.80):

Debit: Bank … £115.20

Debit: Payment Fees Expense … £4.80

Credit: BNPL Clearing … £120

For Sale #2, if the refund is deducted from the next payout, you might see no payout or a smaller payout. Suppose the provider statement shows a payout of £0 for that sale’s period because the refund offset it (this is simplified). In reality, the deduction might reduce a later combined payout. When you record that combined payout, you’ll clear the remaining clearing balance accordingly.

The key is that your clearing account will reconcile to the provider’s statement totals. If there are timing differences at month-end, the clearing balance represents amounts still owed or still being netted.

How to handle multiple BNPL providers (Klarna, Clearpay, Affirm, etc.)

If you use multiple BNPL options, you have two workable approaches:

Option 1: Separate clearing accounts per provider

Pros: easier reconciliation, clear visibility of fees and payout timing by provider.

Cons: slightly more accounts to manage.

Option 2: One combined “Payment Processor Clearing” account with tracking tags

Pros: fewer accounts, simpler chart of accounts.

Cons: reconciliation can be harder if statements differ significantly, and you may lose some clarity.

If your volume is modest, a combined clearing account can be fine. If volume is high or providers behave differently (reserves, dispute rates, payout schedules), separate accounts are usually worth it.

Reporting: how to explain BNPL in your financials

When recorded properly, BNPL does not distort revenue—it simply increases selling expenses (fees) and can affect working capital timing.

On the profit and loss statement:

Revenue reflects the full sales value.

Merchant fees show the cost of accepting BNPL and other payments.

Gross margin remains meaningful because you have not buried fees inside revenue.

On the balance sheet:

BNPL clearing/receivable reflects amounts owed to you at the reporting date.

Reserves show as receivables until released.

Disputes may show as receivables or expenses depending on expected outcomes.

These balances help you understand cash timing and highlight if something is stuck (for example, if the clearing account isn’t clearing to zero, you know reconciliation or settlement issues exist).

Checklist: the simplest “do this every month” routine

1) Post sales from your order system at gross amounts (split net sales and tax properly).

2) Map BNPL tender types to a BNPL clearing account.

3) Post each payout as: bank (debit), fees (debit), clearing (credit).

4) Post refunds as reductions of revenue and tax, with the offset to clearing.

5) Reconcile the BNPL clearing account to the provider’s settlement report.

6) Investigate any remaining clearing balance and classify it (timing, reserve, dispute, pending refund).

7) Keep statements and reconciliation notes attached to the month for audit trails.

When you should get professional help

Many BNPL flows are straightforward, but you should consider professional advice if any of these apply:

You have material reserves, chargebacks, or complex dispute arrangements.

You sell subscriptions, long-term services, or bundled deliverables where revenue recognition is not “at checkout.”

You operate internationally with multiple tax regimes and marketplace rules.

Your BNPL contract includes unusual recourse terms (meaning you might bear consumer default risk beyond normal disputes).

You are preparing audited financial statements or investor reporting and need strict GAAP/IFRS compliance.

Even then, the practical mechanics in your ledger will still look very similar to the clearing account approach described above—the difference is in the policy documentation and any additional disclosures or estimates.

Bottom line: treat BNPL as a payment method, not a different kind of sale

To record income correctly when customers pay via Klarna or similar services, anchor your accounting on the sale itself. Record revenue at the proper time for your business (delivery/fulfillment for goods, service performance for services), at the gross amount the customer agreed to pay. Then record BNPL fees as a separate cost of accepting payment. Use a clearing account to bridge the gap between order activity and bank deposits, so refunds, disputes, and payout timing don’t scramble your books.

Once you set up that structure, BNPL stops being confusing. It becomes just another tender type with its own settlement report—something you can reconcile routinely, measure precisely, and manage confidently.