> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chift.eu/llms.txt
> Use this file to discover all available pages before exploring further.

# PSP payments to accounting

You act as a payment service provider (PSP) for your end-users. You collect money from their customers, keep a commission, and pay out the net amount to their bank. This applies whether your software is a PSP, a marketplace, a platform, or a point-of-sale tool. Your end-users want you to book all of this automatically in their accounting software.

This article explains what "booking a payment in the accounting software" means. It also covers what your end-users must configure first, and what happens at each step. You do not need an accounting background to build this integration. The people who own the books make the accounting decisions.

<Note>
  **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](#what-you-build)). This article describes those choices so you can support that setup, not because you make them yourself.
</Note>

## The money movements involved

A payment flow has a few distinct money movements. The accounting software books each one separately:

| Money movement    | What it represents                                                                             |
| ----------------- | ---------------------------------------------------------------------------------------------- |
| Payment collected | Money you collected from your end-user's customer — the gross amount, before any fee           |
| Refund            | Money returned to your end-user's customer — a full or partial reversal of a collected payment |
| Provider fee      | The commission you kept on that payment — a cost for your end-user                             |
| Payout            | The net amount you transferred to your end-user's bank account                                 |

***

## 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.

| Ledger account              | Role                                                | Debit | Credit |
| --------------------------- | --------------------------------------------------- | ----- | ------ |
| Settlement account          | Net owed to your end-user — money in transit        | 96.97 |        |
| Fee account                 | The commission you kept — a cost for your end-user  | 2.50  |        |
| Deductible VAT (on the fee) | Tax on the fee, reclaimable from the state          | 0.53  |        |
| Clearing account            | The gross collected, held until it matches the sale |       | 100.00 |

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:**

| Ledger account            | Role                                | Debit | Credit |
| ------------------------- | ----------------------------------- | ----- | ------ |
| Internal transfer account | Bridges the settlement and the bank | 96.97 |        |
| Settlement account        | Clears the in-transit balance       |       | 96.97  |

**Bank side (bank journal):**

| Ledger account            | Role                        | Debit | Credit |
| ------------------------- | --------------------------- | ----- | ------ |
| Bank account              | The money actually received | 96.97 |        |
| Internal transfer account | Clears the transfer         |       | 96.97  |

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.

Either way, revenue and VAT stay the responsibility of the sale, not the payment.

***

## 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.

<Note>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.</Note>

***

## 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](/guides/unified-api/overview), 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.

**With a [Sync](/guides/syncs/overview), Chift builds it for you.** Chift's [Payment sync](/guides/syncs/ready-to-use-syncs/payment) provides the mapping screen and runs the booking on its side, on a schedule. Your end-user makes the same choices through Chift's interface. You build neither the screen nor the booking logic.