Journals and deltas

A journal

A journal is what General Ledger sends to your accounting system. One journal covers one business unit and one business date, and lists each account with a debit amount and a credit amount:

{
  "businessUnitId": "EU002",
  "businessDate": "2026-09-23",
  "journalId": 41,
  "accounts": [
    { "accountId": "3000", "debitAmount": 0,    "creditAmount": 800 },
    { "accountId": "2610", "debitAmount": 0,    "creditAmount": 200 },
    { "accountId": "1920", "debitAmount": 1000, "creditAmount": 0 }
  ]
}

• Every journal balances: its debits add up to its credits.
• journalId numbers the journals of a business unit. It increases with every journal for that business unit, across all dates. It is not a count per day.
• A business date on which a store recorded nothing produces no journal.

When journals are sent

General Ledger exports every 30 minutes between 02:00 and 05:30 UTC, every day. Each run sends a journal for every store-day that has something new to send:

• A business day is sent once it has ended in the store's own time zone. A store in Central Europe is normally sent at 02:00 UTC. A store further west, whose day ends later, is sent in a later run that night, or at 02:00 UTC the following night.
• Anything that arrives after the night's last run waits until 02:00 UTC the next night.

The first journal, and every journal after it

The first journal for a store-day holds the day as it stood at that moment. What if more arrives for that day later, for example from a till that was offline, or a transaction sent late?

General Ledger never sends the whole day again. It sends a new journal with only the difference.

So your accounting system posts every journal it receives, as it is, and the day adds up:

the day in your accounts = the sum of all journals for that business unit and business date

This is what "delta" means. A later journal changes the day's figures, and each journal is a complete, balanced posting in its own right, so nothing has to be reversed by hand.

What a delta looks like

A delta journal is calculated per account: what the day is now, minus everything already sent for that day.

Change since the last journal	What the delta journal shows for that account
the account went up on the credit side	a credit for the increase
the account went up on the debit side	a debit for the increase
the account's credit went down	a debit for the decrease. Never a negative credit.
the account is no longer used at all	the full amount already sent, on the opposite side, so the account returns to zero
the account did not change	not in the journal

⚠ Amounts are never negative. A correction that lowers an account appears as a posting on its other side. Your integration must post debits and credits as they come and must not assume that a sales account only ever receives credits.

⚠ Increases stay gross; decreases are netted. When late transactions only add to a day, the delta keeps debits and credits apart, as the first journal does: a late sale of 50 and a late return of 20 on the same sales account give credit 50.00 and debit 20.00. Only when a side has gone down, which normally happens after a recompute, is the decrease moved to the other side and combined with it. Then the account appears with a single net figure.

How far back late transactions are picked up

A transaction that arrives late is picked up automatically if its business date is within about the last month. For anything older, recompute the date. The transaction is stored, and a recompute includes it. See Correcting and resending.

Where else the journals go

Each journal is also stored, unchanged, for ten years. That store is what re-export sends from. It is not a place you can read from directly: to see a day's figures, use the API or the General Ledger tool. To receive the journals, see Receiving the journals.