Klarna and Afterpay Accounting in QuickBooks Online

A customer buys a $600 sofa and chooses Klarna. They pay $150 today and owe three more payments of $150 over the next six weeks. You watch that happen in your Stripe Dashboard and a reasonable question forms: what do I book today?

The instinct is to book $150 and carry $450 as a receivable, then chip away at it as the customer pays. Or to wait until the plan finishes and recognise the whole thing at the end. Both are wrong, and they are wrong in a way that creates real work: a receivable schedule nobody needs, revenue recognised in the wrong period, and a QuickBooks balance that will never tie to a Stripe payout.

The actual answer is that your books already have it right, because Stripe paid you the whole $600 up front. The installment plan is a contract between your customer and Klarna. Your accounting never sees it.

Start a free trial and see exactly what a buy now, pay later sale writes into QuickBooks.

You are paid in full, immediately, and Stripe says so plainly

This is the sentence the whole topic turns on. Stripe's buy now, pay later documentation describes these methods in one line: "Buy now, pay later methods let customers pay in installments over time. You're paid immediately and in full and your customers pay nothing or a portion of the total at purchase time."

Read the second half again. In Stripe's wording, your customer pays "nothing or a portion" at checkout while you are paid "immediately and in full". Those two facts sit in the same sentence because they describe two different transactions that happen to share a shopping cart.

Each provider repeats it in its own documentation. Stripe's Klarna page puts it this way: "When the payment is accepted, you receive the entire order amount (minus fees) in your Stripe account. Klarna collects the initial payment from your customer and any future installment payments." Further down, covering the several repayment options Klarna can offer a shopper, the same page adds: "Regardless of the underlying payment option selected, Stripe makes the full amount of the funds (minus fees) available to you upfront and Klarna collects the purchase amount from your customer, who repays Klarna directly."

Stripe's Affirm page carries the identical construction: "Regardless of the underlying payment option selected, Stripe makes the full amount of the funds (minus fees) available to you upfront and Affirm collects the purchase amount from your customer, who repays Affirm directly."

So whether the shopper picked pay in four, pay in thirty days, or a thirty-six month financing plan, your side of the transaction is the same size and the same shape. The choice they make on the provider's screen has no effect on what lands in your Stripe balance.

There is no receivable, because the provider owns the credit risk

This is the part that changes how you close the month, and it is stronger than most people realise.

If the customer stops paying, you are not the one holding the bag. Stripe's Klarna page is explicit: "If the customer can't repay Klarna, Klarna takes loss liability." Stripe's Afterpay page says that "Afterpay covers losses incurred from customer fraud or the inability to repay installments." The Affirm page says that "Affirm covers losses incurred from customer fraud."

Put those together and the accounting consequence is clean. You have no receivable from the customer, because they do not owe you anything. They owe the provider. You have no bad debt exposure on that sale, no allowance to estimate, no aging bucket to watch. The credit decision was made by Klarna or Affirm or Afterpay at checkout, using their underwriting, at their risk.

That is why a receivable schedule for buy now, pay later sales is not merely unnecessary. It is describing an asset you do not own. The money is already in your Stripe balance. There is nothing outstanding to track.

One caveat worth carrying, because it is an operational obligation rather than an accounting one: both the Afterpay and Affirm pages note that Stripe might contact you on behalf of the provider and ask you to stop or pause a shipment before losses are incurred, and both tell you to comply promptly. That is a fulfilment instruction, not a bookkeeping entry, but it is the one place the provider's risk decision reaches into your operations.

What your books actually receive

Strip away the installment plan and a buy now, pay later sale is an ordinary Stripe charge. It has an amount, a currency, a customer, and a fee, and it produces a balance transaction like any other successful payment.

That matters because Acodei's sync keys on the charge, not on the instrument. Records are created from charge.succeeded and charge.captured events. On a standard real-time connection, the charge becomes an itemized Sales Receipt deposited into your resolved holding account. If your connection has Sales as Payment enabled, the same charge is written as a standalone Payment against the customer instead. If the charge belongs to a Stripe invoice that has already synced, it books as a Payment Receipt applied to that QuickBooks invoice.

Three different records, and two separate decisions choose between them. Sales Receipt versus standalone Payment is an account setting. Payment Receipt is a branch taken when the charge belongs to an already-synced invoice, which is a property of the charge rather than of your configuration. Those are the documented inputs, and the payment method the customer picked is not one of them. The Stripe PaymentMethod entry covers why the instrument itself carries no amount and no status, which is the structural reason it has nothing to contribute to that decision.

If your account runs on daily summary rather than real time, there is no per-charge record at all. Every charge for the day, buy now pay later included, is aggregated into a single QuickBooks entry. That distinction is worth knowing before you go hunting for an individual Klarna sale that was never going to exist as its own row. Daily summary versus real-time sync covers the trade.

The fee is the one number that genuinely behaves differently

Here is what does change, and it is worth understanding properly because it will show up in your margins.

Buy now, pay later methods are not priced like cards. Stripe's documentation for each method points at a separate local payment methods pricing page rather than the standard card rate, so the fee on a Klarna sale and the fee on a Visa sale of the same amount are set by different schedules. Check your own Stripe pricing for the actual numbers, since they vary by method, country, and account.

The mechanics of where that fee lands are unchanged. Stripe records it on the charge's balance transaction, and the balance transaction object reference documents fee as "Fees (in the smallest currency unit) paid for this transaction." The same page documents net as the "Net impact to a Stripe balance (in the smallest currency unit)," and adds: "You can calculate the net impact of a transaction on a balance by amount - fee". Same field, same arithmetic, different input.

In QuickBooks, the fee follows whatever fee method you already configured. By default it posts as a negative line on the Sales Receipt using your mapped Stripe fee product, netting the receipt down to what actually entered your balance. With fee-as-expense configured, the receipt stays gross and the fee posts as a separate Purchase instead. Both are correct. They just answer different questions about what your revenue line should say. How to reconcile Stripe fees in QuickBooks Online is the fuller treatment.

The reporting consequence is the one people miss. Run a Klarna promotion for a month and your blended margin will move even though you changed no prices, because a larger share of your sales carried a different fee schedule. If you review gross margin by period without splitting by payment method, that shift looks like a pricing problem or a cost problem. It is neither. It is mix.

Refunds are where the two ledgers visibly diverge

Everything above says the installment plan never touches your books. Refunds are the one place you can watch that separation happen in detail, and it is genuinely interesting.

Suppose you refund $200 of that $600 sofa while the customer still has two payments left. On your side, that is one ordinary partial refund. Acodei detects it as partial by comparing the refund amount to the original charge amount and writes a Refund Receipt drawing from the same holding account, with lines mirroring what was refunded.

On Klarna's side, the same event is a rescheduling exercise. Stripe's Klarna refund documentation describes it: "Partial refunds update the Klarna order to reflect the new total amount," and if "the partial refund is less than the remaining balance of the order, Klarna deducts the amount from the outstanding balance and spreads refunds evenly across the remaining payments." If the refund is larger than what remains outstanding, "Klarna deducts the refund amount from the outstanding balance and returns the difference."

So your customer experiences a $200 refund as two smaller future payments and possibly a small cash-back. You experience it as one refund of $200. Both ledgers are correct and they will never look alike, because they are tracking different obligations. Do not try to mirror the customer's payment schedule in QuickBooks. There is nothing there to mirror.

Two operational limits from the same page are worth noting. Klarna charges can be refunded "up to 180 days after the payment completes", which is a longer window than some processors allow. And Klarna "doesn't support refunding a payment when it has been escalated to a dispute", which means a refund attempt on a disputed order will not be the resolution path you expected. Recording Stripe refunds in QuickBooks Online covers the general case.

What does not change at all

It is worth saying plainly what stays ordinary, because the list is longer than the list of differences.

Payouts behave normally. Stripe's Klarna page states that "Standard payout timing applies," so buy now, pay later funds join your balance and pay out on the same schedule as everything else. There is no separate settlement stream to reconcile and no special deposit to match.

Disputes exist and are supported. Buy now, pay later transactions can be disputed, and they run through the same dispute machinery.

Capture windows are the one mechanical difference that already has a home. Non-card methods have their own authorization and capture rules, and Klarna's is notably long. Stripe partial capture in QuickBooks owns that ground and covers the windows by method.

And the balance transaction is still the reconcilable unit. Whatever the customer chose at checkout, the thing that ties your QuickBooks record to your Stripe payout is the Stripe balance transaction, same as it is for a card.

Frequently asked questions

Should I book a Klarna sale as accounts receivable?

No. Stripe pays you the full order amount up front, minus fees, so there is nothing outstanding from the customer. The customer owes Klarna, not you. Booking a receivable would create an asset that does not exist and a reconciliation that can never clear.

Do I get four deposits for a pay-in-four sale?

No. You get the full amount once. Stripe's buy now, pay later documentation states that "You're paid immediately and in full and your customers pay nothing or a portion of the total at purchase time." The four payments are the customer repaying the provider, and none of them pass through your Stripe balance.

What happens to my books if the customer stops paying?

Nothing. Stripe's Klarna documentation states: "If the customer can't repay Klarna, Klarna takes loss liability." The Afterpay page says that "Afterpay covers losses incurred from customer fraud or the inability to repay installments." You were already paid. A customer default is the provider's loss, so no entry appears in your ledger and no allowance is required.

Does Acodei handle Klarna or Afterpay charges differently from card charges?

No. Records are created from charge events. The record type is chosen by two documented inputs: an account setting that selects Sales Receipt versus standalone Payment, and whether the charge belongs to an already-synced Stripe invoice. Payment method type is not among those inputs, so a buy now, pay later charge books through the same route as a card charge.

Why did my gross margin drop during a buy now, pay later promotion?

Almost certainly mix, not cost. These methods are priced on a separate schedule from cards, so a period with a higher share of buy now, pay later sales carries a different blended fee rate even with identical pricing. Split your margin reporting by payment method before treating it as a pricing problem.

Where does the buy now, pay later fee show up in QuickBooks?

Wherever your fee method already puts Stripe fees. By default it is a negative line on the Sales Receipt using your mapped Stripe fee product. With fee-as-expense configured, the receipt stays gross and the fee posts as a separate Purchase. Changing your fee method does not rewrite history, so historical transactions keep the treatment they were synced with unless you resync them.

The point

The installment plan is real, but it is not yours. It is an agreement between your customer and a lender who paid you in full at checkout and took the credit risk in exchange for a fee.

Once that lands, buy now, pay later stops being an accounting problem and becomes a pricing one. Your books see a single ordinary sale on the day it happened. The only number that behaves differently is the fee, and the only reporting habit worth changing is splitting margin by payment method so a shift in mix does not read as a shift in cost.

Everything else, the payout, the dispute path, the reconciliation, works exactly as it does for a card.

Start a free trial and watch a Klarna sale land in QuickBooks as one clean record.