Add a sales invoice (interactive workflow)
Add a sales invoice (interactive workflow)
When Alice needs to bill a client, she adds a sales invoice as repository data and then generates a PDF as a derived artifact linked back to the invoice records. The important invariant is that invoice totals, VAT, and references are validated at write time so later reporting and postings can treat invoices as trustworthy inputs.
- Alice confirms she has the account references she will use for invoice line mapping:
cd 2026-bookkeeping
bus accounts list
If she maintains counterparties as reference data, she also checks the customer exists:
bus entities list
- Alice adds the invoice as explicit invoice and invoice-line records using a non-interactive command surface:
bus invoices add \
--type sales \
--invoice-id 1001 \
--invoice-date 2026-01-15 \
--due-date 2026-02-14 \
--customer "Acme Corp"
bus invoices 1001 add \
--desc "Consulting, 10h @ €100/h" \
--quantity 10 --unit-price 100 \
--income-account "Consulting Income" \
--vat-rate 25.5
bus invoices 1001 validate
This is intentionally low-level: the module must have a command surface that allows scripts and UIs to write the same canonical invoice rows without relying on interactive prompting. Interactive prompting can still exist as a convenience mode, but it is not the definition of the workflow’s invariants.
On write, the module rejects missing references (unknown customer when entities are required, unknown income account, unknown VAT class) and rejects internally inconsistent totals rather than writing partial data.
- Alice verifies the invoice is present and consistent by listing invoices:
bus invoices list
Generating the PDF representation and registering it as evidence is a separate workflow step, because it is derived output that must remain linked to the invoice records. That step is covered in the next page.
- Alice records the result as a new revision using her version control tooling.