Accounting code fails on arithmetic, not layout: a total that disagrees with its line items by a cent, a tax rate applied before a discount. Each invoice here computes its own subtotal, tax and total from the actual line items, so the numbers reconcile.
What you can control
- Subtotal, tax and total are computed from the generated line items rather than filled independently.
- The tax rate is adjustable in half-point steps, covering the fractional rates that break rounding.
- A realistic status mix leans toward paid, with a minority overdue — which is what an aged-receivables report needs.
- Line item details can be expanded into a column when you need the individual rows.
What this is not
Tax is applied as a flat percentage of the subtotal. Real tax handling varies by line item, jurisdiction and customer status, so do not use these figures to validate a tax engine.
Questions
Do the totals actually add up?
Yes. Each line item's quantity times unit price feeds the subtotal, tax is a percentage of that, and the total is their sum. If your reconciliation code disagrees, the bug is yours.
Why include draft and overdue invoices?
Because those two states are where invoice UIs break — a draft with no number, an overdue one that needs a warning. A batch of paid invoices tests nothing.
Can I set my own invoice number format?
Partly. The prefix is yours; the year and sequence are generated. The result looks like ACME-2026-04817.