Tabby and Tamara now account for a meaningful share of GCC online checkout. They also settle differently to a card gateway, and getting the accounting wrong overstates your margin while distorting cash flow forecasting.
The customer experience is simple: split the payment into instalments, pay nothing extra. The merchant experience is where it gets interesting — you are paid upfront by the provider, who then carries the credit risk and collects from the customer over the following weeks.
That is a genuinely useful product. It is also a different transaction to a card payment, and your books should reflect that.
What actually happens
- Customer selects Tabby or Tamara at checkout.
- The provider approves them, usually in seconds.
- Your order is confirmed and you fulfil it.
- The provider settles with you — net of their fee, on their cycle.
- The customer pays the provider in instalments over the following weeks.
Step five has nothing to do with you. Your relationship ends at step four.
Four things people get wrong
1. Recognising revenue on the wrong date
Revenue should be recognised when the order is approved and fulfilled, not when the customer finishes paying the provider. Businesses that tie recognition to instalment completion end up with revenue trailing sales by weeks for no good reason.
2. Burying the merchant fee
BNPL fees are higher than card fees — that is the trade for the conversion uplift and the credit risk transfer. Netting the fee off revenue makes your gross margin look better than it is and removes any basis for negotiating rates or deciding where BNPL is worth offering.
Post it to its own account. Then you can answer whether the conversion uplift justifies the cost, which is the actual commercial question.
3. Unmatched settlements
Providers settle in batches covering many orders. If those credits arrive in the bank with nothing matching them to underlying orders, they sit as reconciling items — and after a few months nobody remembers what they relate to.
4. Refunds handled in one place only
A refund processed through the provider's dashboard but never posted in the ledger leaves you overstating revenue and understating the fee reversal. This one is easy to miss because the provider's side looks correct.
The commercial question BNPL raises. Does the conversion uplift exceed the fee difference? For higher basket values it frequently does. For low-value orders it frequently does not. You cannot answer it at all unless the fee is visible as its own line.
How to configure it
| Element | Treatment |
|---|---|
| Revenue | Recognised at order approval and fulfilment, gross of provider fee. |
| Provider receivable | Its own account per provider, cleared when settlement arrives. |
| Merchant fee | Separate expense account, posted per transaction rather than in aggregate. |
| Settlement | Matched to the underlying orders, not posted as a lump credit. |
| Refunds | Posted in the ledger at the same time as in the provider dashboard, with fee reversal where applicable. |
What good looks like
At any point you should be able to answer: how much are Tabby and Tamara holding on my behalf, what did BNPL cost me last month, what share of orders used it, and does the basket size justify the fee.
All four are reports if the structure is right, and guesswork if it is not.
Worth checking. If your BNPL settlements are sitting in a suspense or clearing account that nobody has cleared in three months, that is not a bookkeeping tidiness issue — it means you do not know what you are owed.
BNPL settlements not matching?
Thirty minutes to look at how Tabby and Tamara are posting in your system and what a clean structure would look like.
Book a discovery call