State & lifecycle

Six lifecycles run on the same sale, and they disagree by design.

• The account: applied, approved, active, on hold, cash in advance, closed.
• The order: entered, credit-held, released, shipped, delivered, invoiced.
• The invoice: issued, accepted, approved, scheduled (payer side), paid (in the payer's eyes), applied (in the seller's), closed.
• The payment: initiated, received, settled, funds final.
• Cash application: unidentified, unapplied (payer known, invoices not), partially applied, applied, on account.
• Collections: current, past due by aging bucket, dunning, promise to pay, placed, written off, recovered.

"Settled" and "final" mean different things on every rail:

Sources: Fed Reg CC guide, Nacha, Visa Rules (April 2026), Rule H1 (2026 edition), 11 U.S.C. 547.

Even "final" isn't final in a bankruptcy: payments received in the 90 days before a customer files (a year for insiders) can be clawed back as preferences, subject to defenses such as ordinary course of business. A paid invoice can reopen, so every reversal must reverse the application, re-age the invoice and restart dunning, or your customer chases the wrong people.

Ask an expert: what share of orders hit a credit hold, how long until release, and which transition takes longest overall? My hypothesis is the payer's approval and scheduling; I want the tails, not CRF's medians.

Four lifecycles run in parallel, and they disagree by design:

• Requisition and PO: requested, approved, open, partially received, closed.
• Invoice: received, captured, matched or in exception, approved, posted, scheduled, paid, cleared.
• Payment: proposed, approved, released, sent, then settled, returned or cleared.
• Virtual card: issued, then charged by the supplier (or expired uncharged), then settled.

The word that causes the most trouble is "paid":

Discount and late-fee fights live in these gaps. A buyer that "paid" on day 10 by mailing a check and a supplier that received it on day 14 will disagree about the 2% in good faith.

Model "released", "settled" and "cleared" as separate states. A check can show as paid in the ERP for weeks before it's cashed, and in that window it can be stolen, altered or go stale. A virtual card can sit uncharged while the buyer believes the invoice is closed.

Ask an expert: which transition holds the most invoice-days (intake, match exception, approval, or waiting for the run), and how long do virtual cards sit uncharged?

Four machines run on one purchase, and they end at different times:

• Card: unactivated, active (a virtual card counts once viewed), suspended, terminated.
• Authorization: approved or declined, held, increased or partly reversed, then cleared or expired. Visa gives merchants 10 days to clear an online authorization and 30 for lodging and car rental.
• Expense: draft, submitted, returned or approved, audited, exported, paid, archived.
• The employee's obligation: an advance or personal charge, then repaid, or treated as wages after the IRS's 120 days.

A transaction can outlive its card. Refunds post to canceled cards, late captures land after cancellation, and one issuer processor allows recurring authorizations on expired cards unless the card is canceled. When an employee leaves, cancel rather than reissue: a reissued number flows to every merchant storing the old one through Visa Account Updater.

The word that causes the most trouble is "done":

Legal clocks hang on these states. Illinois' 30-day submission window and the IRS's 60 days run from the expense date. Payment deadlines run from the claim: 30 days in Iowa, New Hampshire and federally regulated Canadian workplaces. New York makes an unpaid agreed reimbursement a misdemeanor 30 days after it's due.

Model the card, the authorization, the expense and the employee's obligation as four machines; the bugs live where one has ended and another hasn't.

Ask an expert: which state transitions generate the most tickets: hold releases, late captures after cancellation, or refunds to canceled cards?

A number has one lifecycle. A sender has several, running in parallel, and the bugs live where they disagree.

The NANP number lifecycle, from the platform's side: spare → allocated to a carrier block → in your inventory → reserved → active → porting out or released → aging → spare again. Aging is law, not policy: a disconnected number must age at least 45 days, and at most 90 days for residential and 365 for business numbers (47 CFR 52.15). Toll-free runs its own clock: reserved at most 45 days, assigned at most 6 months, then 45 days to 4 months in disconnect (47 CFR 52.103).

On top of the number, every sender layer keeps its own state:

Sources: Google launch docs, Meta templates, CTIA short code handbook.

Abroad, add degraded states: delivered but labelled "Likely-SCAM" (Singapore) or "Unverified" (Australia), or delivered with your sender overwritten.

"Approved" in one system rarely means "live everywhere". Show customers state per carrier, and make port-out and release clean up the campaign link, any hosted SMS route (texting on a number whose voice stays with another carrier) and the 911 record.

Ask an expert: which external state drifts out of sync most often (a campaign suspended at one carrier, a paused template, a 911 record left behind after a port), and how long until anyone notices?