Purchase order acknowledgment template with line status fields

Use one row per purchase order line, never per order

A supplier rarely answers an order as a single yes. It accepts one line, moves the promised date on another, and questions quantity or price on a third. An order level status column forces that into one word and loses the detail that planning actually needs. The template repeats the purchase order number and supplier on every row and adds a line number, so each line carries its own answer and the order can still be read as a whole.

Keep the ordered columns immutable

Ordered quantity, unit of measure, unit price, and requested date come from the approved source order and should never be edited once the order has been sent. When a supplier proposes a change, that value belongs in the acknowledged columns, and the value the buyer approves belongs in the committed columns. Overwriting the ordered value is the single change that makes a late delivery impossible to discuss later, because the original agreement has been erased from the record.

• po_number, line_number, supplier, buyer_owner
• ordered_quantity, ordered_unit_of_measure, ordered_unit_price, requested_date
• sent_at, response_received_at

Use a line status vocabulary rather than a free text note

The template's line_status column uses a short controlled vocabulary that maps closely to the line item status codes an EDI 855 would carry, so the same tracker works whether the answer arrived by email or through a portal. Keep the vocabulary short enough that everyone uses it consistently, and put the supplier's own wording in the note column beside it rather than in the status.

• accepted, the line will ship as ordered
• accepted_quantity_changed, accepted with a different quantity
• accepted_date_changed, accepted with a different promised date
• accepted_price_changed, accepted with a different unit price
• partial, part of the line will ship and the balance is outstanding
• backordered, the line is acknowledged but not schedulable yet
• rejected, the supplier will not supply this line
• no_response, no line level answer has been received

Separate what the supplier said from what the buyer approved

A supplier proposal is not a commitment. The acknowledged columns record what the supplier stated, and the buyer_disposition, decision_owner, and decision_at columns record who accepted, rejected, or countered it and when. The committed columns are then derived from that decision, not copied from the supplier's message. Two consequences follow immediately: an unresolved proposal is visible as a decision waiting on an internal owner, and internal delay stops being invisible in supplier performance reporting.

• acknowledgment_type, line_status, acknowledged_quantity, acknowledged_unit_price, promised_date, supplier_note
• buyer_disposition, decision_owner, decision_at
• committed_quantity, committed_unit_price, committed_date

Watch for the four signals that the spreadsheet has run out

A tracker like this works well for a low volume handled by one buyer. It stops working when several buyers edit the same rows at once, when reminders depend on someone remembering, when a supplier's response has to be copied out of an email thread by hand, and when someone needs to prove who approved a change three months later. A file cannot enforce roles, expire a link, stop a reminder at the right state, or keep an append only history. Use the template to establish the column model first, and treat those four signals as the point where the model needs a system behind it.

The same model, running by itself

Pacteva implements the structure this file describes. A reviewed purchase order is imported, each supplier receives a secure expiring link that needs no account or password, and the supplier answers at line level. Proposed changes land in a buyer queue instead of in the order, reminders follow a published policy and stop at the correct state, and the ordered, proposed, decided, and committed values stay distinct with an attributable history. The export uses the same column model as this template, so a team can move without rebuilding its reporting.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.