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

# Accounting to accounting

Your software is an (pre-)accounting system. The businesses that use it often need journal entries to flow automatically to or from another accounting system: because their accountant works in a different tool, or because they are migrating from a legacy system.

This article explains what that synchronisation involves and what your end-users must configure to run it. You do not need an accounting background to read this page. The people who own the books make all accounting decisions.

## Journal entries: the object that moves

A **journal entry** is the fundamental record in any accounting system. It captures a single financial event (a sale, a payment, a cost) as a set of balanced debit and credit lines, each tied to a ledger account.

| Concept        | What it means                                                                        |
| -------------- | ------------------------------------------------------------------------------------ |
| Journal entry  | A record of one financial event, split into debit and credit lines                   |
| Ledger account | A named bucket in the chart of accounts (e.g. "Customers", "Revenue", "VAT payable") |
| Journal        | A logbook for a category of entries (e.g. sales journal, purchase journal)           |
| Partner        | The customer or supplier linked to an entry line                                     |

## What happens when an entry moves between systems

The source system holds the entry. The target system must receive it and book it correctly against its own chart of accounts, its own journals, and its own partner records. This requires translating each element of the entry (accounts, journals, partners) to its equivalent in the target system.

Every journal entry must balance: the sum of debits always equals the sum of credits. That structure is preserved in the target system.

*Account numbers below follow the Belgian PCMN chart of accounts; exact codes differ by country and by accounting plan.*

### Example: a customer invoice entry

A customer invoice of €121 (€100 net + 21% VAT), as it appears in both systems after synchronisation:

| Ledger account                | Account (PCMN)    | Role                        | Debit  | Credit |
| ----------------------------- | ----------------- | --------------------------- | ------ | ------ |
| Customer receivable (partner) | 400 – Clients     | Who owes the money          | 121.00 |        |
| Revenue                       | 700 – Revenue     | What was earned             |        | 100.00 |
| VAT payable                   | 451 – TVA à payer | Tax collected for the state |        | 21.00  |

The entry balances: debits (121.00) equal credits (100.00 + 21.00). This translation happens automatically — you send the entry, and it appears correctly in the target system.

***

## What gets configured by the end-user

### Journals

An accounting **journal** is a dedicated logbook for a category of entries. The end-user selects, for each journal in the source system, which journal in the target system should receive its entries. Where both systems use the same journal codes, this mapping can be pre-filled automatically. Journals the end-user does not want to synchronise can be excluded.

### Ledger accounts

The end-user configures a mapping between the chart of accounts in the source system and the chart of accounts in the target system. Where account codes match between systems (tolerating minor differences such as `00012345` matching `12345`), the mapping can be pre-filled automatically.

For accounts that could not be pre-filled, the end-user completes the mapping manually or chooses one of these fallback options:

* **Create the account:** A matching account is created in the target system automatically.
* **Use a default fallback account:** All unresolved lines fall back to a single account selected at setup.
* **Skip the entry:** Entries that contain an unresolved account are not imported.

### Partners

Entry lines tied to a customer or supplier must link to the correct partner record in the target system. Partners are matched between systems by account number or by identifiers the two systems share. If no match is found, the partner can be created in the target system automatically.

Once a partner is resolved, the link is stored and reused on every subsequent entry for that partner.

<Warning>If a partner is deleted from the target system after setup, entries for that partner fail. The partner must be recreated before synchronisation can continue.</Warning>

***

<Note>
  **Who configures what.** Your end-user, or their accountant, makes every accounting decision: which journals to sync, how accounts and partners map between systems. You build the integration and send the data. The end-user makes those choices in a mapping screen (built by you with the Unified API, or provided by Chift with a Sync; see [What you build](#what-you-build)).
</Note>

## What you build

**With the [Unified API](/developer-guides/unified-api/overview):** You build the sync logic: reading journal entries from your system, sending them to the target via Chift's accounting API, and building the mapping screen for your end-users. Chift normalises the differences between accounting systems.

**With a [Sync](/developer-guides/syncs/overview):** Chift provides a pre-built synchronisation between your system and supported accounting systems. You integrate once with Chift. Your end-users configure the sync through Chift's interface. No mapping screen to build on your side.