Last updated: 2026-05-21

Invoice payment lifecycle

Every invoice in your workspace is in one of two payment states: Unpaid (the default when it lands) or Paid (after you mark it so). That's the entire lifecycle — no "partial", no "overdue", no "scheduled". The two states give you a clean filter for "what do I still owe?" and "what's already settled?" without inventing process Anchorlet can't verify on your behalf.

Anchorlet doesn't decide when an invoice is paid; you do. There's no bank-feed integration, no auto-detection from your accounting software. The Paid state is your assertion that the money has actually left your account.

The two states

  • Unpaid — the default when an invoice is created or extracted. The pill in the list view is neutral muted; nothing demands action.
  • Paid — you've marked it so. The pill turns green. Two optional fields become available: Paid date (when the payment actually went out) and Paid reference (bank statement memo, transaction ID, cheque number — whatever helps you find the payment later in your bank records).

Both Paid date and Paid reference are optional even when the status is Paid. Some legacy invoices are paid-but-date-unknown — that's fine, toggle the status and leave the date blank. The Paid reference field is always optional regardless of status; fill it when you've got a meaningful identifier to thread, leave it blank when you don't.

Marking an invoice paid

Open the invoice — from the issue page (Invoices section) or from the invoice list view. The Payment section on the reviewer holds the three fields:

  1. Toggle Status to Paid.
  2. Optional: enter the Paid date in the date picker.
  3. Optional: enter the Paid reference (free text, e.g. "AIB statement line 14 Jun" or "Cheque #1247").
  4. Save.

To revert: toggle the status back to Unpaid. Anchorlet clears both the Paid date and the Paid reference automatically — the database forbids an Unpaid invoice from carrying a Paid date, and the reviewer treats the reference the same way to keep the form coherent.

Filtering the list

The /invoices page has a Payment status segmented control above the table with three options: All, Unpaid, Paid. Click to filter; the URL updates so the filtered view is bookmarkable.

Combine with the other filters — date range, contractor, property, expense type, extraction status — to narrow further. "Unpaid + last 60 days + Tom Walsh" is one click in each chip.

The URL parameter is paymentStatus=unpaid or paymentStatus=paid (omit the parameter for the All view). Useful when you want to share a filtered link with your accountant or bookmark "everything I still owe".

Where you'll see it

  • Invoice list view — Payment pill in its own column on desktop; in the mobile card view, the pill sits below the amount. Filter via the segmented control above the table.
  • Invoice reviewer — the Payment section with the toggle and the two optional fields.
  • xlsx export — three labelled columns appended at the very end of the spreadsheet:
    • Payment status — "Paid" or "Unpaid" (title-case, accountant-friendly).
    • Paid date — YYYY-MM-DD when populated, blank when not. Same shape as the Invoice date column so a date-sort on either column works identically.
    • Paid reference — the free-text memo, blank when empty.

The three payment columns are appended at the end so any accountant macros pointed at earlier columns (Net, VAT, Gross, etc.) don't shift.

Things to know

  • Unpaid is the default. Every freshly-extracted or manually-entered invoice starts Unpaid. You opt in to Paid; there's no auto-transition.
  • Paid date is optional even when Paid. Some invoices arrive paid-but-date-unknown (legacy receipts, payments made before the invoice was uploaded). Mark them Paid and skip the date.
  • Unpaid + Paid date is impossible. A database CHECK constraint prevents it — toggle to Unpaid and the Paid date is cleared. Defensive, so you don't end up with confusing leftover metadata.
  • Paid reference is free text, not a structured field. Type whatever you'll recognise later: a bank statement line, a cheque number, a transaction ID. Anchorlet doesn't validate or parse it.
  • No reminders or due-date tracking yet. Payment lifecycle is intentionally minimal — the filter answers "what's outstanding?" and that's it. Due-date tracking and overdue alerts are backlog items, not currently in the product.

Next steps