Skip to main content

​
Payments, rails and treasury

Money never moves in GreatBook without belonging to a rail. A rail is a channel money actually moves through - a bank account, a card, a cash box, an employee’s float, a credit facility - and it reconciles against its own source: that bank’s statement, that card’s statement, that facility’s statement, a physical count. There is no single global cash check anywhere in the system, because a single global cash check passes while two rails are wrong in opposite directions.

​
Paying a supplier

The payment writes three kinds of row alongside the entry: unapplied = settlement amount - Σ allocations is derived, never stored. The Close list carries payment_crossfoot as a must-be-zero checksum, so an allocation with no settlement behind it - or a settlement whose allocations do not foot - is a break rather than a rounding difference.

​
The rail accounts

The rail catalogue is itself a Close checksum: a movement on a rail the catalogue does not enumerate is a break, so a new payment channel cannot appear silently.
The per-rail reconciliation is per rail × per currency. One rail carrying two currencies produces two independent tie-outs, because a rail that nets across currencies can hide an FX error inside a correct-looking total.

​
The employee float is a rail, not an expense shortcut

An employee holding company cash is an asset of the company (1280, VAS 141), and every movement of it is booked. Paying a bill out of the float is the same pay operation with the float as the rail - and because the float’s own GL account is 1280, that path credits 1280 once and does not post a second float leg. Double-crediting the float is the specific mistake the code comments against. float_gl_tie is the Close checksum that ties the float’s recorded movements to the 1280 balance.

​
Supplier advances

The advance is an asset until it is applied - it is money the supplier holds that has not yet bought anything. po_advance_pool_settles is the must-be-zero checksum over the pool, which is what makes an advance that was paid and never applied visible.

​
Loans and facilities

One lifecycle covers every facility shape, and the balance is derived from movements rather than stored: drawdown + interest accrued - principal repaid - interest paid. Accrued interest is added to what is owed rather than parked in a separate accrual, so the facility balance at any moment is the number the lender would quote. Per-facility checksums cover the derived balance, the headroom against the limit, and the factoring positions.
FACILITY-BAL, HEADROOM and the factoring checksums are per facility, so the executed count of the Close list expands with the number of facilities on the book. That is one of the reasons a live run’s check count and the 104 defined checksums are two different quantities.

​
Capital and dividends

The 5% personal income tax on a dividend to an individual is withheld at declaration, not at payment, so the liability to the state exists from the moment the dividend does.

​
Where it is enforced

​
The test that would fail if it broke

backend/tests/test_settlement.py covers the payment and allocation paths including the float’s single-credit rule. backend/tests/test_close_checks.py drives the cross-foot and per-rail reconciliation checksums against seeded breaks.