[Blog]()Production # Purchase orders: approvals, changes and verifiable receiving Approval should identify the revision authorized, rather than merely prove someone once clicked “approve.” **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 8 min read **Short answer** Approve a specific order revision showing supplier, lines, quantities and conditions. Define which changes reopen review and who may substitute for the approver. Test permissions and release retries; internal approval does not prove supplier confirmation or physical warehouse receipt. ## Purchase-order revision and authorization Ten tests cover sensitive changes, delegation, permissions and release without duplicates. [Download CSV worksheet]() In this guide - [What exactly should be approved?]() - [Who requests, reviews and releases?]() - [Worked example: revision one does not authorize revision two]() - [What if an executed order changes?]() - [Which tests prevent decorative approval?]() - [How do you prepare a workflow consultation?]() ## What exactly should be approved? An order needs a reference and revision that reconstruct what the approver saw. Preserve requester, supplier, products, units, quantities and relevant conditions. If someone changes those fields later, history should explain the change and whether authorization remains valid. A green status without a revision cannot answer whether one hundred pieces were approved or the one hundred twenty now displayed. The decision should remain understandable after catalog data changes. Business Central documents approval users, substitutes and configurable limits in a purchasing workflow. Its example moves from pending request to release after approval. Not every conceivable change is a supported default event; verify the actual workflow. [Purchase approval reference](). Write your company’s rules before confusing an available feature with a configured policy. ## Who requests, reviews and releases? Decide when requester and approver should be separate. A substitute needs explicit scope and validity rather than logging in through another person’s account. Classify sensitive changes: supplier, quantity, material, destination, date or condition. A descriptive note may follow another rule, but that exception also needs agreement. Test the same control through an import or integration if those paths can modify purchases. Keep the responsible person visible for every decision. ## Worked example: revision one does not authorize revision two **Synthetic OC-A data** OC-A v1 requests 100 pieces from P1. Purchasing proposes v2 with 120 pieces from P2. This exercise requires approval again for those changes. These are not customer prices, documents or decisions. | Step |Content |Expected outcome | | --- | --- | --- | | Request v1 |P1;100 pieces |Awaiting review | | Approve v1 |P1;100 pieces |Authorization bound to v1 | | Propose v2 |P2;120 pieces |Fresh review; preserve v1 | | Release v2 using v1 approval |Changed content |Reject or explicit review | | Approve v2 through authorized substitute |P2;120 pieces |Record identity and delegation | | Release L02 and repeat L02 |Same approved v2 |One released operational order | After v2 is released, accepting fifty leaves seventy outstanding against its one hundred twenty under the agreed acceptance-quantity rule. The approval table does not itself record that arrival. A message prepared for P2 also does not establish receipt or agreement: preserve sent-document status and response separately. This exercise reviews records and sends no supplier communications. Use independent evidence for each stage rather than a single overall “done” label. ## What if an executed order changes? If receipts or material reservations already exist, do not replace the earlier order as though it never happened. Identify the changed portion, what has been executed and which outstanding quantity is affected. A reduction should not delete a receipt; an increase needs appropriate authorization. If the supplier substituted a material, retain the proposal until the responsible person determines acceptability. Operational approval alone does not decide technical requirements or commercial treatment. Odoo publishes Purchase linked with inventory and supplier documents. [Purchase features](). That connection relates processes, but you must demonstrate which action creates a movement in the actual configuration. [Partial receipts]() test arrival and acceptance; [material revisions]() help when the change affects production. ## Which tests prevent decorative approval? - Normal: the approver sees the complete revision and the decision retains contents, time and identity. - Exception: changing OC-A supplier or quantity requires the agreed review; an earlier authorization cannot silently apply. - Retry: repeating L02 preserves one release and allows its result to be queried after a lost response. - Permissions: a requester without approval authority cannot release through a URL, import or integration. - Delegation: the authorized substitute uses their own identity; expired or out-of-scope delegation is rejected. ## How do you prepare a workflow consultation? Complete the [purchase approval worksheet]() for an order that changed before receipt. Bring both revisions and who made each decision. [ERP or custom software]() helps choose an approach; the scope of [manufacturing software]() should describe these controls and exceptions without assuming every available approval feature represents your entire process. ## Bring a purchase changed after approval In a free consultation we can define which revision is authorized and which modifications need fresh review. - Two order revisions showing supplier and lines. - Requester, approver and substitute roles. - Receipts or outstanding quantities affected by the change. [Book a free consultation]()[Ask on WhatsApp]() Related - [Production control]() - [Manufacturing software]() ## Frequently asked questions ### Must every edit request approval again? Not necessarily. Define sensitive changes and exceptions by field. Demonstrate when authorization remains valid and when review reopens. ### Can a substitute use the approver’s account? The proposed control requires their own identity and visible delegation. Shared accounts prevent reconstructing who actually decided. ### Does order approval confirm goods arrived? No. Approval, supplier confirmation and receipt are distinct events. Link them without treating one as evidence of another. ### What happens if release is repeated after a failure? Query the original identity and require one released order. Changed contents require review of a new revision rather than repeating an old action. ## Sources 1. [Business Central purchase approval workflow]()Microsoft Learn 2. [Odoo Purchase and inventory]()Odoo Last updated: October 8, 2026 ## Keep reading [InventoryOct 8, 2026 ### Partial purchase receipts: arrived, outstanding and rejected]()[Internal permissionsOct 8, 2026 ### Roles and permissions: who views, changes and approves in your system]()[Change auditingOct 8, 2026 ### Change audit logs: who changed what and how to investigate a difference]() --- Canonical: https://nightlysoftware.com/en/blog/purchase-order-approvals Updated: 2026-10-08 Description: Test who requests and approves a purchase, which changes need fresh review and how the approved revision is retained without duplicate orders.