Compute
Invoice and payment states
Five separate commercial states track a Compute invoice. See what each one proves, what it does not, and why only a payment-provider read-back means paid.
Five states, never synonyms
An invoice is tracked by five separate states. They advance independently, and none of them can be read as a substitute for another.
| State | What it tracks | What it proves | What it does not prove |
|---|---|---|---|
lithi_invoice_state | The Lithi invoice record itself | The invoice exists and is finalized | Nothing about your finance system or any payment |
erp_sync_state | Whether the invoice reached your finance system | A record was created there | That anyone approved it |
erp_approval_state | Approval inside your finance system | Your own approval workflow completed | That money moved |
mercury_payment_state | The payment at the provider | Where the payment stands with the provider | That your finance system agrees |
reconciliation_state | Whether the records match | Lithi, the provider and your system reconcile | Nothing on its own about a single line |
The milestones
Each milestone is a separate, evidenced event. Reaching one never implies the next.
| Milestone | Meaning |
|---|---|
INVOICE_FINALIZED | The Lithi invoice is issued and its lines are fixed |
ERP_CREATED | A matching record was created in your finance system |
ERP_APPROVED | Your finance system recorded its own approval |
PAYMENT_INITIATED | A payment was started at the provider |
MERCURY_FUNDS_CONFIRMED | The provider confirmed the funds |
Only a provider read-back means paid
Lithi's payment record advances to paid on one thing only: a current read-back from the payment provider. Nothing else moves it.
A Paid label in your finance system is an annotation. It records what your team believes, and it is useful, but it is not settlement and it never advances the Lithi payment record.
PAYMENT_INITIATED is not payment either. It says a payment was started, not that funds arrived, so treat it as in-flight until MERCURY_FUNDS_CONFIRMED.
Hosted payment action values
The hosted payment action carries its own small set of values, separate from the five states above.
| Value | What to do |
|---|---|
unavailable | No hosted action exists yet; use the transfer instructions on your invoice |
ready | Open it and complete the payment on the provider's page |
opened | Someone has already opened it; finish there rather than opening a second one |
expired | Request a fresh action; never reuse an old link |
revoked | Stop and confirm with your finance owner before requesting another |
Reading a state safely
Every status you read carries when it was observed and how long it stays valid. A state older than its validity window is a stale reading, not a current one.
There is no debit operation in the API, so no state here can be advanced by calling something. States move on evidence: a finalized invoice, a created record, an approval, a provider read-back.
If two of the five disagree, that is a reconciliation question rather than a payment question. Take it through adjustments and disputes with the invoice reference and the period.
Related
- Pay a Compute invoice — the steps a billing person takes