The Invoice Lifecycle

An invoice is created, paid, and eventually settled. Its status is never set directly: it is derived from the payments recorded against it.

​

The Statuses

​

Status Is Derived, Not Set

The app reads the status like this, first match winning:

1. Created as a draft and not yet finalized → Draft
2. Voided → Void
3. Every line item’s amount is zero → No Charges
4. Every line item is fully settled → Paid
5. No payments recorded at all → Owed
6. Otherwise → Partially Paid

Settlement is judged per line item, not on the invoice total. This matters on an invoice with lines pointing in opposite directions: a $1,000 expense line and a $1,000 credit line net to zero, but both lines are still open, so the invoice is Owed — not Paid. A total of zero is not the same as nothing left to do. On the invoice page, Status is a read-only field — no control sets it. It moves when money moves. The invoice listing’s bulk Mark As is the one place a status is named directly, and even there the app is being told to record or remove the payments that make the status true, not to relabel anything. The menu reflects the selected invoice’s current state. Here an Owed invoice can be made Paid or Void; Owed is disabled because no transition is necessary.

​

Drafts

Draft is the one status that says nothing about money. A draft is an invoice that exists as a document but has not been finalized: nothing is recorded against it, and it contributes to no total, no report figure, and no reserve. A draft is never typed by hand. Two things produce one:

• Document parsing. An invoice read out of a PDF lands as a draft, for review before it counts.
• The external API. A create call can bring an invoice into being unfinalized.

Drafts appear in the invoice listing by default — a draft is a row someone has to find and finalize — with the status and the amount both in italics. A draft is the one place an invoice’s type and line items are editable. It opens read-only behind an explicit Edit; from there, line items can be added, removed, re-typed, and re-priced, and the type itself can be switched. This is the window in which a mis-parsed invoice gets corrected. Two things a draft does not admit: payments cannot be recorded against it, and it cannot be voided — a draft that should not exist is deleted instead. Editing, relinking, and deleting all stay legal. Finalize turns the draft into an ordinary invoice in place, keeping the same invoice number and the same URL. Its figures enter the totals, its type and line items freeze, and it takes a status from the rules above — normally Owed, with payment recorded from there like any other invoice.

​

Creating an Invoice

​

Dates

Three dates, doing three different jobs:

​

Recording Payments

Payments are recorded per line item. A payment is an amount against one line item, with its own date and an optional memo — the same unit the payment history lists and the app later edits. The Record Payment menu on an invoice offers the two ways to do it: Settling in stages is ordinary: a $15,000 invoice paid in three $5,000 instalments is Partially Paid twice and then Paid.

​

Editing and Removing Payments

The payment history is authored, not append-only. Expanding a line item and opening its history gives every payment on that line — amount and date, both editable — plus Add Payment for another, and a control to remove one. A removed payment shows struck through until the save, and can be restored before then. Revert All Payments, in the invoice’s Actions menu, removes every payment at once and returns the invoice to Owed. A line item never accepts more than its own amount. Payments on a line may sum to less — that is an ordinary partly-paid line — but not to more, and the app reports each line’s outstanding figure as amounts are typed.

​

Worked Example

An invoice with three line items: $1,000 of indemnity and $500 of legal fees on the expense side, and a $300 salvage credit on the income side. Its total is $1,200 expense — the net of the three. A first Record Partial Payment pays the law firm $500 and nothing else: The invoice is Partially Paid. Two lines are still open — including the salvage credit, which is money owed to the business and settles only when the recovery is actually collected. Mark Paid in Full from here settles both remaining lines on one date, in both directions at once: Now every line is settled, so the invoice is Paid. Settlement is judged line by line, which is why settling the legal fees in full still left the invoice Partially Paid.

​

What Can and Cannot Change

Every invoice figure feeds the company’s record of where its money is. That record is only ever added to — a correction is a new entry that supersedes an old one, never a rewrite of what was already written. That single rule decides which changes an invoice allows, and what each one costs.

​

Frozen at Creation

These are the facts the money record was built from. Changing one would not correct that record, it would contradict it. So a correction is not an edit: it is a void and a replacement — void the invoice, create the right one. The freeze never loosens. Reverting a paid invoice to Owed does not unlock its line items, and no later status makes the type or the amounts editable again.

​

Changes That Don’t Touch the Money

The invoice’s dates, its memos, and its files describe the money without moving it. They can be changed on any invoice at any status: a fully paid invoice’s dates and memos edit in place, with its payments left exactly where they are.

​

Changes That Move the Money

Everything else writes to the money record, and divides by whether the app has to walk the invoice through other states to get there. Direct — each writes its own entry. Recording a payment, editing one, removing one. The status simply follows from the result. Composed — the app walks the invoice through the intermediate states. Some changes are legal only on an invoice with no payments against it. Rather than refuse, the app takes the payments off, makes the change, and puts them back, all in one step, after a dialog that spells out the steps — because none of them are visible in the result. Relinking a paid invoice to a different event is the clearest case. Its payments were attributed to the old event, so the invoice cannot simply be pointed elsewhere while they stand:

1. Remove every recorded payment.
2. Move the invoice to the new event.
3. Re-record every payment against the new event.

The invoice passes through Owed on the way and ends up back at Paid. Voiding a paid invoice composes the same way, without the third step — the payments are reverted and the balances zeroed as part of the void.

​

Voiding

Voiding keeps the invoice as a record but takes it out of the numbers entirely. A voided invoice:

• still appears in listings, its status reading Void;
• is excluded from every count, total, and report figure;
• opens read-only, offering Restore, and can still be relinked or deleted.

Voiding a paid invoice reverts its payments as part of the same step, so there is nothing to undo first. Restoring a voided invoice returns it exactly as it was, and its figures come back into the totals.

​

Deleting

Deleting removes the invoice from the app. Unlike voiding, it is not a browsable state — the invoice is gone from listings and reports, and deletion is final. Deleting an invoice has no preconditions: an invoice with payments recorded against it can be deleted, and the app unwinds them.

​

Bulk Actions

Company Event Financials and the Event Financials Tab both support multi-select. With rows selected, the Actions menu offers:

• Mark As — move the selected invoices to Owed or Paid in bulk, with a confirmation that spells out what will be recorded or removed.
• Approve — see Approvals.
• Link and Unlink — change the primary entity in bulk. Company-wide only; inside an event’s own tab the event is fixed.