Proforma to order: keep the commercial handoff clear
By Mrunal Walke2 min read
Link a proposed transaction to its accepted order and later invoice without treating a proforma document as proof of payment or fulfilment.
On this page
A proforma invoice describes a proposed transaction. In an operational workflow, it should be clearly distinguished from the accepted order, final invoice and payment record. Linking those records helps sales and finance understand what the customer agreed to and what still needs to happen.
Identify the proposal version
Record the customer, proposed items or services, quantities, prices, currency and validity information. Give each revision a clear reference. If a customer accepts an older version, the team should be able to see exactly which terms were accepted rather than overwriting them with the latest draft.
Zoho Books documents a way to create a proforma using its estimate workflow. Check how your chosen accounting system represents the document; a display label alone should not change its underlying accounting behaviour.
Define the acceptance event
Decide what evidence your business requires before proceeding: an authorised acceptance, purchase order or another agreed instruction. Store that evidence with the accepted version. A salesperson opening the PDF is not an acceptance event.
| Record | Operational meaning |
|---|---|
| Proforma or proposal | Describes the proposed transaction |
| Acceptance evidence | Identifies the agreed version |
| Sales order | Records the authorised fulfilment instruction |
| Invoice | Records the billing document |
| Payment | Records an actual settlement event |
The legal and tax treatment depends on the transaction and applicable requirements. Finance should approve the document and posting rules rather than infer them from the workflow labels.
Handle a changed quantity
Imagine a hypothetical proposal for ten units is accepted for eight. Preserve the original proposal, create or record the accepted revision and ensure the order uses eight. An integration that copies the original quantity without checking acceptance can create both a fulfilment error and a billing dispute.
If an advance is required, record its confirmed receipt separately. Do not mark the order paid because the customer says a transfer was initiated. Reconcile the payment through the normal finance process.
Test conversion and partial fulfilment
Check a revised proposal, an expired proposal, a partially fulfilled order and a repeated conversion request. The same acceptance event should not create two orders. Use stable references between documents and expose any conversion failure to an owner.
Before launch, trace one fictional transaction from proposal through order to invoice and payment. Compare customer, quantities, currency and references at each step. Keep the workflow clear enough that a colleague can explain the current commitment without searching a chain of attachments.
Further reading
Primary reference. The workflow examples above are illustrative implementation guidance, not customer results.
Explore the related Dood resource. To discuss your workflow, contact Dood System.
