Matched, Unmatched, Reconciled: How Payment Status Actually Works

Every payment record in Invoice Generator, whether you entered it by hand, imported it from a CSV, or it was created by a bulk "mark as paid" action, carries a status field with one of two values: matched or unmatched. That single field is what determines whether a payment counts toward any invoice's balance at all, and understanding how it changes — including in cases you might not expect, like deleting an invoice — explains a lot of otherwise surprising behavior around invoice totals.

What "Matched" and "Unmatched" Actually Control

A payment's status isn't cosmetic. Only payments attached to an invoice contribute to that invoice's paid amount and, by extension, its status — a payment sitting unmatched, with no invoice group ID, exists in your payments list but is invisible to every invoice's balance calculation. This is exactly why an unmatched CSV import row doesn't wrongly nudge any invoice toward "paid": until a payment is explicitly attached to an invoice, it simply isn't counted as money against anything.

Three Ways a Payment Becomes Matched

A payment ends up matched to an invoice through one of three paths. You can record it manually against a specific invoice from the start, which sets its status to matched immediately. The CSV importer can auto-match it using its reference/name-and-amount heuristic at import time. Or you can take an existing unmatched payment and reconcile it manually, which is a dedicated action that sets its invoice group ID and flips its status to matched in one step. All three paths converge on the same result — a payment row with an invoice group ID and a matched status — and all three trigger the same recalculation of that invoice's paid amount and status afterward, so it doesn't matter which path a payment took to get there; the invoice behaves identically either way.

Reconciling Isn't the Same as Creating

It's worth being precise about what "reconcile" means here, because it's a distinct action from creating a payment. Reconciling takes a payment that already exists — most commonly one the CSV importer left unmatched — and attaches it to an invoice you specify, rather than creating a new payment record. If the payment being reconciled was previously attached to a different invoice, that invoice's balance gets recalculated too, since it just lost a payment it was previously counting. This matters if you ever need to correct a mis-attached payment: reconciling it onto the right invoice doesn't leave a phantom balance behind on the invoice it's being moved away from.

Deleting an Invoice Doesn't Delete Its Payments

Here's the behavior that catches people off guard: deleting an invoice does not delete the payment records that were matched to it. Instead, every payment that was attached to that invoice group has its invoice group ID cleared and its status reset to unmatched — the payment rows themselves stay in your payments list, just detached and no longer counting toward anything. This is a deliberate design choice: a payment represents money that actually moved, real income received from a real client, and deleting the invoice it happened to be filed under shouldn't make that historical record of income disappear. If you delete an invoice by mistake, or delete one that was a duplicate of another, the payments that were on it survive and are available to reconcile onto the correct invoice afterward.

Deleting a Payment Is Different — and Final

Deleting a payment record itself, as opposed to deleting the invoice it's attached to, does remove it outright — there's no equivalent "detach instead of delete" softening for this action, since a payment is the record of the money itself, not a reference to it. If the deleted payment was matched to an invoice, that invoice's paid amount and status get recalculated immediately afterward to reflect its removal, which can flip a fully-paid invoice back to partially paid or unpaid if the deleted payment was what had covered the difference.

Every Status Change Is Recalculated From Scratch, Not Adjusted

Whenever a payment's matched status changes for any reason — a new match, a reconciliation, a deletion — the affected invoice's paid amount isn't incremented or decremented by the delta. It's recomputed from zero by summing every currently-matched payment against that invoice group. This is why editing an invoice's paid amount directly, by hand-setting a number somewhere in its data, doesn't stick: the next time any payment event touches that invoice, the recalculation overwrites whatever was there with the true sum of its matched payments, which is also exactly why the bulk "mark as paid" action inserts an actual payment record rather than editing a paid-amount field directly — a bare field edit would simply get reverted the next time this recalculation ran.

Reading a Payment's Status at a Glance

In practice, "unmatched" in your payments list means one of three things happened: a CSV row the importer couldn't confidently place, a payment that was reconciled away from an invoice onto a different one, or a payment orphaned by deleting the invoice it used to belong to. None of those are error states exactly — they're payments waiting for a human decision about where they belong — but an unmatched payment sitting there for a long stretch is usually worth a quick look, since it represents money you've received that isn't currently reducing any client's outstanding balance in your reports.