Invoice Lifecycle

Every invoice progresses through a series of statuses. The path depends on the collection method.

Status flow

Send Invoice flow

draft → sent → paid ✓
              → overdue → paid ✓
              → void ✗

Immediate (POS) flow

pending → paid ✓
        → void ✗

Status reference

Status	Description	Editable?
Draft	Created but not sent. Only available in Send Invoice mode.	Yes
Sent	Email delivered to customer with payment link. Awaiting payment.	No
Pending	Immediate (POS) flow — QR generated, awaiting on-chain confirmation.	No
Paid	Payment confirmed on-chain. Terminal state.	No
Overdue	Due date has passed without payment. Automatically transitioned.	No
Void	Cancelled by merchant. Terminal state. Cannot be reopened.	No

Key behaviors

• Draft → Sent: Triggered when you send, one invoice or several at once, with either Send (email) or Send for on-chain payment. An email is sent either way and the invoice becomes immutable. See Sending invoices.
• Sent → Overdue: Happens automatically when the due date passes. A background process checks daily.
• Voiding: Available for any non-paid invoice. Voiding is permanent — create a new invoice instead of “unvoiding.”
• Paid: Once the invoice’s full amount is settled — on-chain, offline, or a mix of both — it’s marked paid.

Recording offline payments

Not every client pays on-chain. From the invoice detail page, record a payment made outside Plirin — a bank transfer, cash, card, or check — on any invoice in sent, pending, or overdue status. This is a dashboard-only action; there is no separate flow, it’s the same invoice moving toward paid by a different route.

Dashboard-only in v1

Recording, removing, and restoring offline payments (and listing an invoice’s payment history) is available from the merchant dashboard only. API keys are denied these operations in v1 — recording a fictitious payment is the obvious abuse path for an API-key-driven integration, so this stays a human-in-the-loop action until a customer need argues otherwise. See GraphQL Mutations.

Partial payments. A recorded amount can be less than what’s owed — the invoice stays open, showing the reduced amount remaining, and you record additional payments (offline, on-chain, or both) until the balance reaches zero. Amounts always validate against the current balance, so you can never record more than what’s still owed (OVERPAYMENT_REJECTED) — there’s no credit-balance concept in v1.

If a customer has already made a partial offline payment and pays the rest on-chain via the hosted invoice page, they’re charged only the remaining amount, not the original invoice total.

Removing a mistaken entry. If you record a payment in error, remove it with a reason. Removing (and restoring) a payment needs its own permission, separate from recording one. Today the owner and managers have both and cashiers have neither, so the permission does not yet separate anyone’s duties. When someone other than the owner removes or restores a payment, the owner gets an email with who did it and why. Payments on a void or draft invoice cannot be removed or restored (INVOICE_VOID_OR_DRAFT). Removing a payment that had fully settled the invoice reopens it: back to sent, so it is chased and payable online again, or straight to overdue if its due date has already passed on your calendar. A payment can’t be removed once a credit note has been issued against the invoice after it was recorded, since that would rewrite the balance a document already relied on; issue a new credit note instead.

Restoring. A removed payment can be restored, with a reason, after you confirm it (a restore can mark the invoice paid). It is only restored if it still fits the current balance. If another payment (on-chain or offline) has landed in the meantime and the amount no longer fits, restoring fails (RESTORE_WOULD_OVERPAY) rather than silently overpaying the invoice.

History. Each removal and restore is kept as its own entry under the payment in the invoice’s payment history, for example “Removed by Sam on 3 Aug 2026: entered twice” and “Restored by Owner on 4 Aug 2026: two separate visits”. The date is on your business’s calendar.

Refunding an offline payment

Plirin does not move money for an offline payment, so refunding one is a record of what you paid back yourself: choose Refund on the paid invoice, pick the offline payment, and enter the amount, method and date. It settles a credit note and can be voided if entered by mistake. To correct a payment that was recorded in error, remove it (with a reason) instead. See Refunds.