Order.co SKU approvals need substitution controls

Snapshot what the SKU approval covers

The direct answer is to treat SKU-level approval as a versioned decision with explicit limits. Preserve requester and business purpose, catalog and item identifier, manufacturer and supplier, description, specification, unit and pack size, quantity, price and currency, contract reference, destination, delivery window, budget and accounting dimensions, policy version, approver, conditions, and decision time. A later catalog value should not replace the item facts the approver actually reviewed.

Define whether the approval permits quantity tolerance, price variance, partial shipment, back order, alternate supplier, equivalent item, changed pack, or destination change. If a condition is not stated, the workflow should not infer it from a similar description or category. Transaction approval and item approval are also different: one may authorize the overall spend while another controls the product, safety, security, sustainability, or operational attributes of each line.

Detect substitutions before commitment or receipt

A substitution can occur when the purchase order is created, when the vendor confirms, during fulfillment, or when a receiving team records what arrived. Compare manufacturer part number, supplier item, description, specifications, quantity, unit, pack, price, ship-to location, and requested date at every stage. Route a material difference to the right procurement, finance, operations, safety, security, or technical owner rather than allowing the original approval to follow automatically.

Preserve who proposed the substitute, reason, evidence, availability, commercial effect, policy evaluation, reviewer, approval or rejection, supplier acknowledgement, and effective time. A substitute can be acceptable for one location or use and prohibited for another. The fact that an order was routed to a vendor does not prove vendor acceptance, fulfillment, delivery, receipt, suitability, or authorization of the changed item.

Reconcile every downstream line to the decision

Order.co describes line-level reconciliation and a lifecycle that reaches payments. Maintain the chain from requisition line to approval, purchase-order line, supplier confirmation, shipment, receipt or return, invoice line, exception, accounting entry, payment instruction, bank response, settlement, credit, and correction. Each link should carry stable identifiers and quantities so a split shipment, partial receipt, price change, or substituted SKU cannot inherit an unrelated approval.

Three-way matching or automated reconciliation supports review; it does not establish that goods were acceptable, received by the right party, coded correctly, free of duplicate liability, tax-correct, or authorized for payment. Exceptions need an owner and disposition. If the system proposes a match or code, retain inputs, rule or model version, output, confidence where available, human action, and correction without converting automation into approval authority.

Test one order with partial and substitute fulfillment

Use a requisition with two approved SKUs, a supplier that substitutes one pack size, a partial shipment, a quantity overage, a changed delivery location, and an invoice that uses the supplier's identifiers. Reviewers should reproduce the original policy and approvals, detect each change, route only the material exceptions, record supplier acceptance, verify the receipt, reconcile every invoice line, and keep payment authorization and settlement as separate evidence.

Order.co's official page supports the attributed descriptions of requisition-to-payment workflow, transaction- and SKU-level pre-approvals, purchase-order creation and vendor routing, fulfillment stages, line-level reconciliation, and payment processing. It does not establish a buyer's catalog, policy, contract, configured approval, supplier acceptance, item equivalence, receipt, invoice validity, coding, payment authority, settlement, compliance, savings, or outcome. Procurement, finance, accounts payable, operations, security, safety, tax, legal, supplier, and budget owners retain those decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Procurement Technology Current will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.