Who configures what. Your end-user, or their accountant, makes the accounting choices: which accounts hold the money in transit, the fee, and the collected amount, and which journal each entry uses. They know their own books; you never make these choices. They make them in a mapping screen at setup. You build this screen with the Unified API, or Chift provides it with a Sync (see What you build). This article describes those choices so you can support that setup, not because you make them yourself.
The money movements involved
A payment flow has a few distinct money movements. The accounting software books each one separately:What happens in the accounting software
Timing is the key point. You collect the money now, keep your fee, and pay the net to your end-user’s bank a few days later. Because of that gap, the collected money cannot go directly to their real bank account. It has not arrived there yet. The system first places it in a settlement account. A settlement account is a holding account for money the provider owes but has not yet paid out (“money in transit”). When your software pushes a payment, it posts the explicit side of the journal entry to the accounting software: the gross on the clearing account, the fee on the expense account, and the VAT if applicable. The settlement account side is implicit. Chift resolves it from the journal and balances the entry automatically. The breakdown below shows why your end-users must configure a few accounts first.The payment, when you collect it
Take a card sale of €100.00 gross. The provider fee is €2.50, with deductible VAT on the fee of €0.53. The net owed to your end-user is €96.97. Total debits equal total credits.
Nothing has reached the real bank yet. The €96.97 stays in the settlement account until the payout arrives.
The payout, a few days later
When the €96.97 arrives in your end-user’s bank, two entries record the movement. The first clears the settlement account against an internal transfer account. The second, in the bank journal, records the money arriving in the bank against the same internal transfer account. Settlement side:
Bank side (bank journal):
After all steps, both the settlement account and the internal transfer account net to zero. The fee and its VAT stay on their own accounts. The clearing account still holds the €100.00 gross. The next section explains why.
Connecting a payment back to a sale
A payment is only the money side of a transaction. The sale itself is a separate record: the revenue earned and the VAT charged to the customer. Your end-user books the sale separately, often through the invoice or point-of-sale flow. Your payment flow must never book the collected money as revenue. That would count the sale twice. So the gross you collect needs a place to sit, apart from revenue, until it is matched to the sale. Your end-user chooses between two options:- Route the gross to a clearing account (the usual default). The €100.00 sits on a dedicated clearing account. Later, their accountant matches it against the customer’s open invoice in the sales ledger. This completes the match. It works even when you cannot tell which specific sale a payment belongs to.
- Route the gross directly to the customer’s receivable. When you can link a payment to a specific invoice, the collected amount clears that customer’s balance directly. You need no clearing account. This option requires you to know the matching invoice on your side.
Required mappings
Before you can synchronize payments, your end-users configure a small set of mappings. A mapping links a movement in your software to the right account and journal in their accounting software. Your end-user, or their accountant, configures the mappings once, at setup.The settlement account and its journal
Your end-user links each payment method or balance you settle (for example, one per currency) to a dedicated journal. A journal is a logbook for that stream of entries. Its counterpart is the settlement account that holds the money in transit. Your end-user selects the journal and account for each one. This is deliberately not their real bank account. The real bank is used only when the payout arrives.The clearing account
This account holds the gross collected until it is matched against the sale. Your end-user selects one, unless they route payments directly to a customer’s receivable instead.The fee account
This is the expense account for your commission. The fee includes VAT, so your end-user also maps a deductible VAT code for it. This code lets the accounting software record the tax and reclaim it from the state.You do not map your end-user’s real bank account here. Their side records the payout that arrives in it, either automatically through their bank feed or manually by their accountant. The integration does not book it.
What you build
Your end-user always makes the accounting choices above: the settlement account and its journal, the clearing account, and the fee account and its VAT treatment. These are decisions about their own books, not yours. You build the integration around those choices. What you build depends on how you connect to Chift. With the Unified API, you build it yourself:- a mapping screen where your end-user selects their journals and accounts (you fetch the options from their accounting software and present them);
- send logic that books each movement on the right side: the gross to the clearing account or receivable, the fee (and its VAT) to expense, and the net to the settlement account;
- logic that prevents duplicate bookings when a sync runs more than once.