Understand document types, partial payments, customer links, credits and recorded refunds.
Choose the record for the transaction#
A document describes the business event. A payment records money. Keep those purposes separate when choosing a workflow.
| Choice | When it fits | What it changes |
|---|---|---|
| Quotation | A proposal for the customer to review. | Does not establish that money has been received. |
| Invoice | An issued request or record of an amount due. | Preserves the issued seller, buyer and amount snapshots. Later corrections use controlled records. |
| Receipt | Evidence of a recorded payment. | Must refer to an actual recorded payment; a checkout return screen is not a receipt. |
| Credit or reversal | A supported correction to financial history. | Preserves the original records. A credit does not itself initiate a gateway refund. |
Full payment, partial payment and customer access#
Enabling partial payments allows the supported workflow to record amounts below the outstanding total. It does not forgive the remaining balance. Review the invoice’s current payment state before fulfillment or delivery.
Customer document links are explicit, scoped and expiring. Share the intended link rather than giving a customer a staff login or broad workspace access.
Correct history without rewriting it#
Issued records, posted journals and source snapshots remain protected. Use an eligible credit, audited payment reversal or confirmed return. Review cash-drawer and stock consequences separately.
Automatic provider refunds, fiscal clearance and carrier actions are available only where an implemented workflow explicitly supports them. Never treat an operator note as independent provider verification.
Keep the active workspace, actual business requirements and current setup summary in view. A guide explains a choice; it does not make that choice for you.