BusDK module CLI reference

BusDK module CLI reference

This section explains what each BusDK module is for, when you usually use it, and which command to try first. Command names follow CLI command naming. Most pages show a short synopsis and a few practical examples first; for the full flag list, run bus <module> --help.

The adjacent aiz toolchain is documented here too. It is not dispatched through bus, but it follows the same deterministic CLI style for single-file .aiz compression and offline restore with unaiz.

If you are starting a new workspace

Most users read these module pages in roughly this order:

  1. bus, bus-init, and bus-config to create a workspace and set company-wide defaults.
  2. bus-accounts and bus-period to define your chart of accounts and accounting periods.
  3. bus-files, bus-attachments, bus-bank, and bus-invoices to inspect incoming evidence files and bring source data into the workspace.
  4. bus-reconcile and bus-journal to connect source rows to accounting entries and maintain the ledger.
  5. bus-reports, bus-status, and bus-validate to review readiness, produce reports, and catch problems before close or filing.

If you need architectural background on why modules are independent and how they integrate, see Independent modules and Modularity.

For cross-module capability scanning, use the BusDK module feature table. It aggregates feature rows from each module repository FEATURES.md and shows user-visible capability, interface type, evidence, coverage, and maturity in one table.

Data files and path ownership

Each module that owns workspace data defines where its data files live. Today these are conventional names at the workspace root (for example accounts.csv, periods.csv, datapackage.json). Only the owning module may write to those files or apply business logic to them; other tools that need read-only access should use the owning module’s documented command and file contract. The design allows future configuration of paths (for example in a data package) so that end users can customize where data is stored without breaking how other tools discover it. bus-files is the deliberate exception in this list: it is a filesystem-facing parser/finder surface for local evidence files and does not start from a canonical workspace dataset.

Core entrypoints are bus, bus init, bus config, bus data, bus preferences, and bus status. Use these when you need to dispatch commands, initialize a workspace, maintain datapackage.json, inspect low-level datasets and schemas, or check workspace readiness.

Local interfaces are bus api, bus api provider books, bus api provider data, bus api provider session, bus sheets, bus books, bus ui, and bus portal. They expose workspace data through HTTP, provider adapters, and browser-facing UIs.

Automation and developer tooling live in bus dev, bus agent, bus run, bus update, bus secrets, bus shell, bus gateway, bus factory, bus events, bus init, bus inspection, bus faq, and bus bfl. bus dev focuses on module-repository workflows, bus run focuses on user-defined prompts/scripts/pipelines, and bus shell provides an interactive or one-shot command shell that dispatches through bus. These modules rely on bus-agent where agent runtime execution is required. bus secrets provides deterministic secret reference storage and resolution for step-level environment configuration. bus gateway, bus factory, and the API/provider modules support integration and service composition around the same workspace data.

Accounting domain modules are bus ledger, bus accounts, bus balances, bus entities, bus customers, bus vendors, bus period, bus files, bus attachments, bus invoices, bus memo, bus journal, bus bank, bus reconcile, bus assets, bus loans, bus inventory, bus payroll, and bus budget.

Reporting, quality, and filing modules are bus reports, bus replay, bus validate, bus vat, bus pdf, bus filing, bus filing prh, and bus filing vero.

All current top-level modules in this superproject have matching end-user pages under this reference section, including the supporting modules that are less often part of the first accounting workflow pass such as bus books, bus faq, bus files, bus gateway, bus inspection, bus portal, bus preferences, bus shell, bus status, and bus ui.