An invoice and a payment are separate business records. A clear workflow helps the team know what happened, who owns the next step, and where financial information must be reviewed.
Scope note: This is a general record-management guide. It does not provide legal, tax, accounting, credit, collections, pricing, payment-processing, or financial-performance advice. It does not claim that any product can create, send, collect, reconcile, or automate an invoice or payment.
Keep the states distinct
Use definitions your authorized business, finance, and compliance reviewers approve.
| State | What it should mean |
|---|---|
| Work record | What was documented as performed or still open |
| Estimate or quote | A proposed commercial record, not an accepted payment |
| Invoice | A formal request for payment under the approved terms |
| Payment record | Evidence that a payment was received or initiated, as applicable |
| Reconciliation | An authorized review of whether related records agree |
| Exception | A record that needs human review, correction, or escalation |
Do not mark a job as paid because work was completed, an invoice was created, or a message was sent.
Assign ownership
For each state, name the team or person responsible for the next approved action. The process should state who may create, edit, approve, void, refund, export, or reconcile a record.
When an amount, payment method, tax treatment, cancellation, refund, credit, deposit, chargeback, or collection issue is involved, follow the business’s authorized policy and the applicable terms. Do not rely on a generic public guide to make that decision.
Use only authorized data
Public examples must never include a real customer name, address, contact detail, invoice number, job note, rate, line item, payment method, account identifier, receipt, financial screenshot, export, log, credential, or token.
Use synthetic examples that cannot be linked to a real transaction. Keep production records in the authorized system and access them only through the roles approved by the business.
Review before customer communication
Before a customer receives a financial communication, the team should verify the intended recipient, approved content, supporting record, sender, and next action for an exception.
A message sent is not proof of delivery or agreement. A payment attempt is not proof of settlement. The final state should be supported by the authorized record.
Test a limited workflow
Test a synthetic scenario from work record through the financial handoff. Confirm that the team can identify the source record, the owner, the permitted change, and the correction path at every step.
If an outcome cannot be explained, pause the workflow and resolve the record before expanding it.
Discussion
Which financial handoff in your process is hardest to verify without relying on an assumption?