> ## 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. # GreatBook > AI-native, data-first accounting. A double-entry general ledger as the system of record, with durable agents doing the boring work behind a human gate. # GreatBook GreatBook is an accounting system whose system of record is a double-entry general ledger. Durable agents read the documents, classify them and draft the journal entries. People approve document and workpaper proposals. Native subledger, reversal and system-origin events follow their canonical domain controls, and every source reaches the book through the same single writer. It is not a chat window bolted onto a spreadsheet, and it is not an LLM with write access to your accounts. It is a ledger with hard guarantees, and an agent org that works in front of it. **Status:** the ledger engine and the five agents are built, tested and deployed. This documentation describes what runs today. Pages carry status markers so it is clear what is live, what is staged and what is planned: 🟢 Live · 🟡 In Development · ⚪ Planned · 🔵 Future. ## The document-intake path in one line Two document lanes, two gates, one writer. ```mermaid theme={null} flowchart LR TW["Typewriter
compose a document"] --> G1 UP["Clerk intake
drop in a PDF"] --> G1 G1["Gate 1 · a human
intake approval"] --> BK["Bookkeeper
drafts a balanced entry"] BK --> G2["Gate 2 · a different human
posting approval"] G2 --> GL["General Ledger
immutable, hash-chained"] ``` Nothing from either document lane reaches the ledger without passing both gates, and the two gates must be cleared by two different people. Other accounting-event origins do not pretend to begin in intake; their canonical controls converge on the same writer and immutable ledger. **"Awaiting posting" never means "posted."** It means a journal entry has been drafted and is waiting for a second person. The only status that means the book moved is **Posted**, and only then does an entry number exist. ## Where to start The failure class this system exists to remove, and why a derived value cannot drift. What the system promises, the code that enforces each promise, and the test that proves it. One document, from a blank form to a posted journal entry, with the real screens. The layers, the five graphs, the two gates, and why the two dependency trees are separate. ## The five agents Each agent has a narrow job and a hard boundary. Two of them can never write to your books at all. One drafts but cannot post. None of them can approve anything, because approval is always a person. Turns your data into a real document. Pick one of 146 document types, fill the schema-driven form, and it renders a PDF and hashes the exact bytes. It files nothing. Reads documents that arrive, classifies them against your SOPs, links related documents, checks for duplicates, and flags anything unclear for a human. It does not fix and it does not approve. Launched when a document clears the intake gate. Drafts one balanced journal entry, shows the proposed debits and credits, and pauses. It cannot post. Re-checks the books against themselves: the hash chain, the GL invariant sweep and orphan rows. Its database sessions are opened read-only, so the database itself would refuse a write from it. Runs the close checklist across five steps, proposes adjusting entries, and produces the statutory mapping. It proposes; it never posts. ## A working example A supplier VAT invoice for 1,100,000 VND from Thanh Long Textile Co., Ltd needs to reach the books. GreatBook: 1. Opens the schema form for `supplier_vat_invoice`, one of 146 declared document types. 2. Renders the document live as you type, then validates, renders the final PDF, takes a SHA-256 of those exact bytes, stores the PDF and writes the row, all or nothing. 3. Refuses to let you approve the document you just composed, and says why rather than showing a button that fails. 4. Lets a designated approver sign it. The approval is recorded against the bytes that were hashed. 5. Hands the approved document to the Clerk's intake queue on one button, and records the handoff on the document's permanent record. 6. Shows a reviewer everything the agent extracted, field by field, with any flags the Clerk could not settle itself. 7. Takes the intake approval, which says only "this document is real and correctly extracted". Nothing is in the ledger yet. 8. Launches the Bookkeeper, which drafts `Dr 1200 Inventory 1,100,000 / Cr 2000 Accounts payable 1,100,000` and stops at the posting gate. 9. Refuses the posting approval from anyone who submitted, drafted, edited or approved that document. A third person approves it. 10. Writes exactly one balanced, immutable, hash-chained entry through the single writer, attributed to the checker. Every step is attributable. Every posted entry is chained to the one before it. The only way to remove an entry is to post a reversing one. The Guides tab walks this exact document through every screen it touches. ## What makes this different from an LLM with database access The judgment is genuinely an LLM's. Reading a scanned Vietnamese fax and deciding it is a supplier VAT invoice rather than a canteen invoice is exactly the work an LLM is better at than a rules engine. The accounting is not. Balance, immutability, idempotency, the hash chain and the period lock are enforced by code and by database constraints, before any write, on every write. There is no probability distribution over whether an unbalanced entry posts. GreatBook puts the two on opposite sides of a gate. The agents propose, the engine refuses anything that would break the book, and a person decides. ## Where to go next The on-ramp. Sign in, compose, approve, post, read the ledger, close a period. Submitter, intake approver, posting checker, document approver, accountant, auditor, developer. The honest status board, including the things that are not built yet. The garment manufacturing platform whose physical movements post their financial effect here.