How an Invoice Is Stored: One Row per Line Item, Plus a Full Copy

An invoice looks like one document, so you'd expect it to be one row in a database. It isn't. Each saved invoice is stored as several rows that share an ID, and each row also carries a full copy of the whole invoice. That design explains how invoices can be searched, how edits are saved, and why an invoice's ID never changes even though its rows are rewritten on every save.

One Row per Line Item

When you save an invoice, the server writes one row for each line item. Each row has that item's description, quantity, and rate, together with the fields every invoice has: invoice number, who it's billed to and from, total, currency, issue and due dates, payment terms, notes, terms, and status. An invoice with five line items becomes five rows. An invoice with no line items still gets one row, with the line-item columns left empty.

Splitting items into rows makes them easy to query. Reports and lookups can work with individual items and quantities without opening up the whole document.

The Group ID Holds the Rows Together

Every row of an invoice shares an invoice group ID, which is created once when the invoice is first saved. That group ID is the invoice's real identity. Share links, payments, comments, view tracking, the audit trail, and recurring schedules all refer to the group ID, never to an individual row. Loading an invoice means fetching every row with that group ID in your workspace and combining them.

Each Row Also Holds a Full Copy

Separate columns can't capture everything on an invoice: discounts, tax settings, custom fields, payment schedules, design choices such as font and accent color, and recorded payments. So every row also stores a full JSON copy of the complete invoice. When the app shows you an invoice, it reads that copy. The separate columns are mainly there for querying, and the copy is what puts the document back together exactly as you saved it.

Invoices saved before the full copy existed are still supported. If a row has no copy, the app rebuilds the invoice from the separate columns, calculating each line's amount as quantity times rate.

Edits Replace All the Rows in One Transaction

Saving an edit doesn't update rows in place. Inside one database transaction, the server deletes every row for that group ID and inserts a new set built from the edited invoice. This handles every kind of change the same way: an added line item, a deleted one, or a reordered list all simply produce a new set of rows.

Because it happens in a transaction, nobody ever sees a half-saved invoice. Other requests see either the old rows or the new ones. The audit entry for the edit and any update to the recurring schedule are written in the same transaction, so the history never says an edit happened if it didn't.

The group ID never changes, so nothing that points to the invoice breaks when its rows are replaced. Payments, comments, and share links stay connected through every edit.

How Currency Is Recorded

Each row stores the currency as a short code and symbol together, such as EUR(€). That value comes either from the currency code and symbol on the invoice, or by looking up the selected currency in the built-in list of countries and their currencies. The full copy also keeps the code and symbol as separate fields. Recording the currency on every invoice, rather than only in a workspace setting, is what lets one workspace hold invoices in different currencies, and what lets reports keep separate totals for each currency instead of adding them together.

Why This Matters to You

Most of the time you'll never notice this design, but it's behind some guarantees you rely on. Saving is all-or-nothing, so an invoice can't be half-saved. Everything linked to an invoice stays linked when you edit it. And the invoice you reopen is rebuilt from the complete copy you saved, with nothing lost.