> ## 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.
# Two layers on the same documents
> Bookkeeping and accounting are not two piles of paperwork. They are two layers of depth on the same documents, and the split is already in the schema, on one row.
# Two layers on the same documents
The usual way to divide finance work is by **document**: you do the bills, I do the payroll.
GreatBook does not divide it that way, because that is not where the difficulty is.
It divides by **layer**, on the same documents.
**The rule, in one test.**
If the fix is *"find the missing or mismatched document, or correct what it says"*, it is the **bookkeeping** layer.
If the fix is *"decide what this belongs to, or what the period needs"*, it is the **accounting** layer.
## A supplier invoice, read twice
A supplier VAT invoice for fabric arrives.
Two people look at the same piece of paper and ask completely different questions.
| | Bookkeeping layer | Accounting layer |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The question | **Is it real, does it tie, has it settled?** | **Where does it belong, what does it cost, what does it mean for the period?** |
| The verb | match, reconcile | dimension, allocate, cost, judge |
| On this invoice | is there a purchase order behind it? A goods receipt against that PO? Does the quantity tie? Has the payment left the bank, and does the bank line match? Is AP control still equal to the sub-ledger? | which style and colorway is this fabric for? Which production order absorbs it? What cost centre, flow, cost nature? If one payment covered three invoices, how does it allocate? Is any of it a prepayment belonging to next period? |
| Grain | the **document** and its chain | the **line** and its attribution |
| Rulebook | thin, and near-identical at every company that buys things | rich, and different at every company |
| Fails as | a chain gap, an untied control account, an unreconciled bank line | an unattributed line, an unallocated payment, an unabsorbed cost |
Both people are looking at the same invoice.
**Neither one owns it.**
## The split is already in the database, on one row
This is not a metaphor about how work feels.
A single journal entry line carries both halves, side by side:
```mermaid theme={null}
flowchart TB
L["journal_entry_lines
ONE ROW"]
L --> BK["the bookkeeping half
account_id
debit_amount / credit_amount
currency · exchange_rate
debit_base · credit_base"]
L --> AC["the accounting half
activity
party_id · party_type
cost_object_id
flow
cost_nature"]
BK --> P["established by matching,
then the human posting gate"]
AC --> M["margin by style
cost by object
P&L by dimension"]
```
The sub-ledger tables split the same way, table by table, without being forced to:
| Table | Layer | Why |
| -------------------------------- | -------------- | --------------------------------------------------------- |
| `obligations` (bill, invoice) | bookkeeping | the payable or receivable itself |
| `settlements` (payment, receipt) | bookkeeping | money moved on a rail, reconciled against bank evidence |
| `rail_evidence` | bookkeeping | the bank statement side of that reconciliation |
| `security_deposits` | bookkeeping | the deposit obligation's own grain |
| `employee_float_movements` | bookkeeping | advance, spend, settlement: the float holder's ledger |
| **`allocations`** | **accounting** | *which* obligations a settlement covers, and for how much |
| **`advance_applications`** | **accounting** | the same act, without cash moving |
A payment is bookkeeping: it left the bank and it matches a bank line.
*Which bills it settles* is accounting: that is an attribution decision about the very same payment.
**The stocks case is the clearest illustration.**
Stock **movement** and its reconciliation are bookkeeping.
Stock **costing and valuation** are accounting.
One Close checksum straddles that line and is split in two for exactly this reason: `NEG-STOCK-QTY` is a movement error, `NEG-STOCK-VALUE` is a valuation error, and sending every valuation error to the movement worklist would waste the wrong person's afternoon.
The layer map is a **generated artifact** covering 54 prototype tables, 18 operational flows and 146 document types, and the agents' rulebooks, the product and this page all read the same file.
Three surfaces cannot disagree about the division if there is only one copy of it.
## Where each layer starts and stops
The captain's own GL-flow diagram is usually read as a journey from left to right, with the bookkeeper owning the left part.
Under the layered rule that reading is wrong.
The left half is not the bookkeeper's *part of the trip*; it is the bookkeeping **layer of every hop**, and the accounting layer runs above it the whole way.
```mermaid theme={null}
flowchart TB
B1["1 · bookkeeping
record · match"]
B1 --> GL["General Ledger"]
GL --> CF["cash flow
liquidity"]
GL --> ARAP["2 · AR / AP
obligations
open · settled · aged"]
CF --> BC["3 · book close +
financial reporting"]
ARAP --> BC
BC --> KC["GL carry-forward
kết chuyển"]
KC --> PL["P&L / margin"]
KC --> BS["balance sheet"]
PL --> CD["company data
dimensions"]
BS --> CD
NA["operations data"] --> CD
CD --> EPM["EPM
deeper analysis"]
classDef bk fill:#e8f4ff,stroke:#3b82f6,color:#0b2545
classDef ac fill:#fff4e8,stroke:#f59e0b,color:#3b2405
classDef na fill:#f1f2f4,stroke:#9ca3af,color:#1f2937
class B1,GL,CF,ARAP bk
class BC,KC,PL,BS,CD,EPM ac
class NA na
```
| Hop | Bookkeeping layer | Accounting layer |
| --------------------------- | ---------------------------------- | ------------------------------------------------------------ |
| 1 · record to the GL | record and match the document | dimension the line as it posts |
| GL to cash flow | the cash position, bank reconciled | the cash flow *statement*, a close deliverable |
| 2 · GL to AR/AP | obligations open, settled, aged | allocations, and what each settlement attributes to |
| 3 · close and reporting | nothing; the layer is done | accruals, prepayments, depreciation, revenue cutoff, costing |
| the carry-forward | nothing | the carry-forward itself, **verified by assurance** |
| P\&L, margin, balance sheet | nothing | margin needs cost objects, so it needs the analytical layer |
| company data and dimension | nothing | "tag dimension" *is* this layer, named on the diagram itself |
| EPM | nothing | analysis over a dimensioned GL |
**The bookkeeping layer finishes at hop 2.**
The accounting layer is present at hop 1, on the very first posting line, and is the only layer from hop 3 onward.
Assurance runs across both: continuously on the left, close-gated on the right.
**The obligation lifecycle is the same idea in miniature.**
Sign an office lease and a payable arises.
Take a customer deposit and a refund obligation arises.
Production completes and that refund obligation converts into a customer receivable.
Money moves and the obligation disappears.
Each of those transitions is bookkeeping.
*What the transition attributes to, and when it is recognised*, is accounting.
## The service ladder, and where GreatBook actually sits
Firms selling client accounting services usually describe their offering as a five-rung ladder.
It is a useful shape, and it is worth being precise about what it is.
**This five-rung ladder is the popular customer-facing framing of client accounting services, not a single canonical published framework.**
The AICPA and CPA.com **CAS 2.0 Practice Maturity Model** names **three** advisory tiers above a compliance foundation: *CFO Finance*, *CFO Business Insights* and *Trusted Business Advisor*, with CAS 1.0 as the cloud-based bookkeeping foundation.
The five rungs below are the service ladder as clients hear it described.
They are **not** an AICPA framework, and this page does not attribute them to one.
| Rung | What it covers | Layer | Where it lives | State today |
| ------------------------------------- | ------------------------------------------------------------------------------------------- | ----------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **1 · Transactional foundation** | recording and categorising daily transactions, reconciliations, organising receipts | bookkeeping | **Data** | 🟢 Live. Document → intake gate → posting gate → immutable GL entry |
| **2 · Operational processing** | day-to-day AP and AR, cash, payroll, tax filings | bookkeeping | **Data** | 🟢 Live workspaces: native Books registers, payments, unified Transactions and W1–W7 Matching |
| **3 · Financial reporting and close** | period-end review, month-end reconciliations, balance sheet and P\&L, management dashboards | accounting | *the accounting desk* | 🟢 Accounting Desk is live for close controls, allocations, costing and adjustments; broader analytics remains incremental |
| **4 · Virtual finance leadership** | proactive analysis, forward-looking strategy | - | - | ⚪ Reserved. Deliberately deferred |
| **5 · Strategic advisory** | owner-level advice and planning | - | - | ⚪ Reserved |
| **Assurance, across 1 to 3** | continuous checks on the matching layer, close-gated checks on the analytical layer | **both** | **Audit** | 🟢 Live. Seven check families, a nightly sweep, a durable register |
**The assurance row is the point.**
Assurance is not a rung.
It runs along the side of the ladder, auditing the bookkeeping layer on matching and the accounting layer on analysis, which is why it gets its own workspace rather than a tab inside somebody else's.
## What this means on screen
The rail names the workspaces, and the workspace names are the ones to use:
| Rail entry | What it is | Layer |
| ------------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------- |
| **Data** | the bookkeeping workspace: intake, the upload desk, the operations grid, and the matching that establishes a document | the matching layer |
| **Audit** | the assurance workspace: exceptions, sweeps, and the two-lane worklist | across both |
| **Forms** | composing a document of record from one of 146 schemas | feeds both |
| **Books** | the unowned data view: the ledger, sub-ledgers, review, payments, statements | both, read |
| **Audit → Actions** | the human worklist, **split into the two lanes** | routed by layer |
| **Actions** | the agent-run inbox: failures, blockers, stale runs, no-change completions, artifacts and receipts | operational evidence |
An exception carries the layer that failed, and that tag is what routes it: a break in the matching layer goes to the bookkeeping lane in **Audit → Actions**, a break in the analytical layer goes to the accounting lane.
Those are two different people's afternoons, and the register says which.
```mermaid theme={null}
flowchart TB
DOC["ONE document
e.g. a supplier VAT invoice"]
DOC --> L1["the BOOKKEEPING layer
Is it real, does it tie, has it settled?
AP · purchase orders · contracts
payments and reconciliations · floats
VAT invoices · goods receipts · stock movement
thin, standard rulebook"]
DOC --> L2["the ACCOUNTING layer
Where does it belong, what does it cost?
dimensions · payment allocations
costing, production and sample cost objects
stock valuation
accruals · prepayments · depreciation
revenue cutoff · carry-forward
rich, per-business rulebook"]
L1 --> GATE["ONE human posting gate
ONE writer
THREE distinct people"]
L2 -->|proposes| GATE
GATE --> LEDGER["immutable GL entry"]
LEDGER --> AUD["assurance"]
AUD -->|"layer = matching"| L1
AUD -->|"layer = analysis"| L2
```
Notice what the diagram does **not** show: a second write path.
Both layers propose into the **same** human posting gate and the same single writer.
Adding an analytical layer added a lot of judgment and exactly zero new ways to reach the ledger.
## What is honestly not built yet
Recorded here rather than left for someone to discover.
* **The dimension vocabulary is built, but analytical reads remain bounded.** The [dimensions owner](/greatbook/capabilities/dimensions#vocabulary-and-read-coverage) records the catalog and explicit missing-column behavior.
* **`close_gated` is explicit-only.** The 26 close-gated checksums run for a finished period from the monthly job or a question naming one of their controls, not from the routine full sweep.
* **Durable workflows stop at metadata.** A guarded resume activates workflow-step metadata but does not yet execute a complete accounting operation.
* **Guarded actions remain narrow.** The closed staged set reaches W3 Matching decisions, Typewriter approve/submit, adjustment decisions, fiscal close/reopen, typed business reversal and workflow resume; it still excludes generic writers, payments, intake/posting decisions and arbitrary routes.
* **Replay safety is exact, not key-only.** A reused journal source key must carry the same immutable facts, and the paired native obligation uses stable source identity in the same transaction; conflicting facts refuse instead of duplicating or returning a misleading prior result.
* **Reserved future agent names** are not shipped agents and do not change the two live workflow layers.
## Related
* [The exception system](/greatbook/agents/assurance) - the lane tag, and what a person does with a finding
* [Who does what](/greatbook/roles) - the human roles behind the gates
* [The agent org](/greatbook/agents/index) - the five agents and their lanes
* [The Close checksums](/greatbook/capabilities/close-list) - all 104, tagged by phase and by layer
* [Dimensions](/greatbook/capabilities/dimensions) - the analytical columns and the gap behind them