Accounting workflow overview
Accounting workflow overview
This page describes the end-to-end bookkeeping flow for BusDK. It assumes a dedicated repository workspace for the accounting year, with workspace datasets (tables plus schemas) and evidence files stored as repository data. Version control is an implementation choice; the core invariant is that workspace datasets and their revision history stay reviewable and exportable. End users can run the local bookkeeping UI (bus books) to work through this flow in a browser.
- Create the bookkeeping repository and scaffold baseline datasets:
bus init
bus init orchestrates module-owned init commands so each module remains the authoritative owner of its datasets and schemas.
- Define master data that other modules depend on:
bus accounts add --code 3000 --name "Sales income 25.5%" --type income
bus entities add --id CUST-ACME --name "Acme Oy"
bus period add --period 2026-02
bus period open --period 2026-02
The chart of accounts maintained by bus accounts becomes the shared reference for postings and reports. Durable counterparties maintained by bus entities keep names and identifiers consistent across invoices, bank imports, and filings. Period control managed by bus period is created with bus period add (periods start in state future); bus period open then transitions the chosen period to open so posting can begin. Close and lock establish the boundaries that prevent later drift.
- Treat evidence as first-class repository data by registering attachments:
bus attachments add documents/2026-02-14-bank-statement.pdf --desc "Bank statement February 2026"
Receipts, invoice PDFs, bank exports, VAT filings, and other documents are archived through bus attachments, and other datasets reference attachment identifiers so provenance remains attached to the records that rely on it.
- Record day-to-day activity as explicit invoice and journal records:
bus invoices add --type sales --invoice-id INV-1001 --invoice-date 2026-02-14 --due-date 2026-03-14 --customer "Acme Oy"
bus journal add --date 2026-02-14 --desc "Sales invoice INV-1001" --debit 1700=125.50 --credit 3000=100.00 --credit 2930=25.50
Invoicing via bus invoices writes validated invoice rows and can produce postings by appending to the shared journal dataset. Direct ledger postings via bus journal remain balanced and append-only, because the journal is authoritative for the financial statements.
- Import bank activity and reconcile it against invoices and postings:
bus bank import --file imports/2026-02-bank.csv
bus reconcile match --bank-id BANK-2026-02-14-001 --invoice-id INV-1001
bus bank normalizes and validates bank statement data, and bus reconcile links bank transactions to invoices or journal entries. If reconciliation reveals missing bookkeeping (for example fees or unrecorded purchases), record the missing source data and run matching again so the change history stays explicit.
For deterministic planning and approval flows, use Deterministic reconciliation proposals and batch apply, including first-class bus reconcile propose/apply.
When onboarding historical data from an external ERP, use Import ERP history into canonical invoices and bank datasets, which covers profile-driven imports and custom script paths.
- Close each period with a repeatable, script-friendly sequence:
bus validate
bus vat report --period 2026-02
bus vat export --period 2026-02
bus period close --period 2026-02 --post-date 2026-02-28
bus period lock --period 2026-02
bus reports trial-balance --as-of 2026-02-28
Validation via bus validate ensures schemas and invariants are still satisfied. VAT is computed and exported via bus vat as repository data for archiving and filing. The period is closed and locked via bus period, and the financial output set is generated via bus reports.
For migration-quality controls before close, use Source import parity and journal gap checks.
- Record close boundaries as revisions:
After the close outputs are generated and reviewed, Alice records a revision using her version control tooling so the period boundary is easy to return to later.
At year end, the same pattern applies to the final period, producing a reproducible, audit-friendly year-end revision for long-term retention.