> ## Documentation Index > Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt > Use this file to discover all available pages before exploring further. # The seven sub-ledgers > Settlement, costing, payroll, loans, VAT, adjustment notes and consolidation - all posting through the one engine, all reconciling as a whole. # The seven sub-ledgers A sub-ledger is where the operational detail of one business domain lives: the individual bills, the stock movements, the payroll lines, the facility drawdowns. The GL holds the control totals. GreatBook has seven of them, and the rule that makes them a system rather than seven systems is that **every one posts through the same engine**. Nothing writes the GL with raw SQL. ## The seven | # | Sub-ledger | Migration | What it records | | - | -------------------------------------------------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------- | | 1 | [Settlement, rails and the AP/AR spine](/greatbook/capabilities/subledgers/settlement) | `0003` | obligations, settlements, allocations, advances, deposits, employee float, and the nine payment rails | | 2 | [Inventory and costing](/greatbook/capabilities/subledgers/inventory-costing) | `0004` | goods receipt, issue to WIP, labour and overhead absorption, finished goods, COGS | | 3 | [Payroll](/greatbook/capabilities/subledgers/payroll) | `0005` | employment contracts as a time series, gross to net, social insurance, PIT, cost-bracket allocation | | 4 | [Loans and treasury](/greatbook/capabilities/subledgers/loans-treasury) | `0006` | facilities, drawdowns, interest accrual, repayment, factoring with and without recourse | | 5 | [VN VAT and statutory tax](/greatbook/capabilities/subledgers/vat-statutory) | `0007` | the input and output VAT register, deductibility, foreign-contractor tax | | 6 | [Adjustment notes](/greatbook/capabilities/subledgers/adjustment-notes) | `0008` | credit and debit notes against an existing bill or invoice, without editing it | | 7 | [Consolidation, intercompany and FX revaluation](/greatbook/capabilities/subledgers/consolidation) | `0009` | intercompany mirrors, period-end revaluation, equity and dividends | ## Three rules every sub-ledger obeys **1. It posts through `LedgerService.post_entry`.** Each operation records its own sub-ledger row *and* posts its journal entry through the single writer, in the caller's transaction. The row and the entry are one atomic fact. **2. Its balances are derived, never stored.** A bill's outstanding amount, a payment's unapplied balance, the AP and AR control totals, the advance pools, the rail balances, stock on hand, the weighted-average unit cost, WIP, the facility balance, the VAT position: all computed from the rows plus the GL. There is no `balance` column anywhere to drift. See [Nothing stored that can be derived](/greatbook/capabilities/derived-balances). **3. A control-account leg and its sub-ledger row are one fact.** Every path that credits AP control `2000` or debits AR control `1100` goes through `settlement.record_obligation`, the single obligation writer. A control credit with no sub-ledger row behind it is a balance the book cannot explain, and the Close checksums catch it. ## How the families interlock The sub-ledgers are not seven silos. They share the control accounts, so they reconcile as a whole. ```mermaid theme={null} flowchart TD P["3 · Payroll"] -->|"production-direct labour → 154"| C["2 · Inventory & costing"] C -->|"material bill: GRNI cleared, obligation opened"| S["1 · Settlement / AP-AR"] P -->|"net · PIT · SI become bills that settle on rails"| S L["4 · Loans & treasury"] -->|"factoring buyout settles on a rail"| S L -->|"non-recourse factoring derecognises the AR"| S N["6 · Adjustment notes"] -->|"changes obligation.due, never the original"| S N -->|"moves the 133 / 3331 position"| V["5 · VAT & statutory"] C -->|"input VAT on the material bill → 1300"| V S -->|"output VAT on the invoice → 2100"| V S --> X["7 · Consolidation"] ``` Four of those edges are worth naming, because each one is a checksum: * **Costing labour is payroll labour.** A production-direct employee's employer cost flows to `1210` (VAS 154), which is exactly the labour the WIP balance consumes. Sub-ledger 3 feeds sub-ledger 2. * **Payroll and factoring settle on rails.** Net pay, PIT and social insurance bills, and factoring buyouts, all move through sub-ledger 1's rails, so they reconcile against bank evidence like any other payment. * **Factoring reads the obligation.** Non-recourse factoring derecognises the receivable, so `obligation.due` goes to zero; recourse factoring is secured borrowing and the receivable stays on the books. The Close checksums police that distinction. * **Notes move due, and move VAT.** An adjustment note changes what is owed and the 133 or 3331 position, without editing the document it adjusts. ## Ties to the dong Sub-ledgers 1 to 6 reproduce **worked v12 workbook data to the dong**. That is the fidelity bar: not "the logic looks right" but "the same inputs produce the same numbers the workbook produced". | # | What it ties to | | - | ----------------------------------------------------------------------------------------------------------------------------------- | | 1 | bill dues, AP control, per-rail per-currency reconciliation, employee float 7,500,000 | | 2 | `total_154` of 84,073,484.8485 / 28,927,272.7272 / 17,636,363.6364; WIP nets to 0; the 627 pool at 9,000,000; landed cost exact-sum | | 3 | net 61,135,250; PIT 2,297,932; social insurance 16,960,000; employer cost 80,393,182; production labour 29,447,727 into 154 | | 4 | facility balance from movements; headroom; recourse factoring keeps the AR, non-recourse derecognises it | | 5 | input VAT 5,800,000; output 0; net 5,800,000 recoverable; per-line integrity; the 133 tie | | 6 | a credit note moves a bill's due to 2,805,000 with the original frozen | **Sub-ledger 7 is different, and says so.** Intercompany, FX revaluation and equity are *proposed only* in the v12 workbook: the flows are specified but never worked, so there is no data to tie to. It is built from the schema's field, enum and formula specification instead, which is what the workbook intends but never executed. That distinction is recorded rather than glossed, because "ties to worked data" and "built from spec" are different claims. ## Where they are enforced All seven live in `backend/app/logics/finance/`, one module each, plus `derive.py` for the balances and `close_checks.py` for the reconciliation surface. ``` settlement.py rails.py costing.py payroll.py loans.py tax.py adjustments.py consolidation.py derive.py close_checks.py ``` Each module's docstring carries its account legs as a table. Those tables are the source of the per-page tables in this section, so the documentation and the code cannot drift without the docstring drifting first. ## Related * [The Close checksums](/greatbook/capabilities/close-list) - the reconciliation surface across all seven * [Nothing stored that can be derived](/greatbook/capabilities/derived-balances) - rule 2, in full * [The general ledger](/greatbook/capabilities/general-ledger) - the engine they all post through * [The dual IFRS + TT200 chart](/greatbook/capabilities/chart-of-accounts) - the accounts their legs name