What should a finance team verify before implementation?

Given an approved requisition and sufficient budget commitment on the cost center; when a buyer creates a PO referencing the requisition with line quantities, unit prices, delivery dates, and ship-to address; then system assigns a sequential PO number, reserves commitment, links requisition lines, logs transmission with timestamp and method, and transitions requisition to PO-Issued; (negative) when remaining budget commitment < 0 then POST returns 422 with problem+json code INSUFFICIENT_BUDGET and deficit amount_minor.

Purchase Order Creation from Approved Requisition

Q: What is Purchase Order Creation from Approved Requisition?

Purchase Order Creation from Approved Requisition is an ERP workflow guide for Procurement & Supplier Management. It focuses on Purchase Orders.

Purchase Orders is where ERP discipline either begins or breaks.

Purchase Order Creation from Approved Requisition looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.

The expected business outcome is specific: Supplier receives legally binding purchase order within one business day; budget commitment is locked in real time; requisition status transitions to PO-Issued; audit trail links requisition to PO.

The control flow a finance team actually needs.

Workflow map for this ERP process, including exception handling and audit evidence.

Step 1

PO Reference Originating Requisition ID...

Step 2

Block PO Issuance When Remaining Budget...

Step 3

PO Transmission Be Logged With...

Step 4

PO Number Format Is Configurable Per...

Step 5

PO PDF Generation Complete Within 3...

The ERP surface involved.

Module

Purchase Orders

Actors

Buyer, Procurement System, ERP

Tier

Tier 1

Finance area

Procurement & Supplier Management

Region lens

US and UK finance teams

Publication date

April 20, 2026

PO must reference originating requisition ID on every line; system must block PO issuance when remaining budget commitment is insufficient (< 0) and surface the deficit amount; PO transmission must be logged with timestamp and delivery method; PO number format is configurable per entity (prefix + zero-padded sequence); PO PDF generation must complete within 3 seconds; all money fields use `*_minor + currency_code` per ADR-001.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Control area	Requirement	Acceptance proof
Control 1	PO must reference originating requisition ID on every line	Given an approved requisition and sufficient budget commitment on the cost center
Control 2	system must block PO issuance when remaining budget commitment is insufficient (< 0) and surface the deficit amount	when a buyer creates a PO referencing the requisition with line quantities, unit prices, delivery dates, and ship-to address
Control 3	PO transmission must be logged with timestamp and delivery method	then system assigns a sequential PO number, reserves commitment, links requisition lines, logs transmission with timestamp and method, and transitions requisition to PO-Issued
Control 4	PO number format is configurable per entity (prefix + zero-padded sequence	negative) when remaining budget commitment < 0 then POST returns 422 with problem+json code INSUFFICIENT_BUDGET and deficit amount_minor.
Control 5	PO PDF generation must complete within 3 seconds	Supplier receives legally binding purchase order within one business day; budget commitment is locked in real time; requisition status transitions to PO-Issued; audit trail links requisition to PO.
Control 6	`all money fields use *_minor + currency_code per ADR-001.`	Supplier receives legally binding purchase order within one business day; budget commitment is locked in real time; requisition status transitions to PO-Issued; audit trail links requisition to PO.

Audit evidence is a chain, not a folder.

Evidence layer	What should be preserved
Business event	An approved purchase requisition triggers a buyer notification; the buyer reviews requisition line items, selects a preferred supplier from the approved vendor master, and creates a standard purchase order with line-level quantity, unit price, delivery date, and ship-to address. The system validates open budget commitment against the cost center, reserves the commitment amount, assigns a sequential PO number, and transmits the PO to the supplier via EDI or email portal.
Control rules	`PO must reference originating requisition ID on every line; system must block PO issuance when remaining budget commitment is insufficient (< 0) and surface the deficit amount; PO transmission must be logged with timestamp and delivery method; PO number format is configurable per entity (prefix + zero-padded sequence); PO PDF generation must complete within 3 seconds; all money fields use *_minor + currency_code per ADR-001.`
Acceptance proof	Given an approved requisition and sufficient budget commitment on the cost center; when a buyer creates a PO referencing the requisition with line quantities, unit prices, delivery dates, and ship-to address; then system assigns a sequential PO number, reserves commitment, links requisition lines, logs transmission with timestamp and method, and transitions requisition to PO-Issued; (negative) when remaining budget commitment < 0 then POST returns 422 with problem+json code INSUFFICIENT_BUDGET and deficit amount_minor.
Data record	purchase_order { id: string, po_number: string, requisition_id: string, supplier_id: string, entity_id: string, status: enum, transmission_method: enum, transmission_logged_at: timestamp, external_id: string }; purchase_order_line { id: string, po_id: string, requisition_line_id: string, quantity: int, unit_price_minor: int64, currency_code: char(3), delivery_date: date, cost_center_id: string }; budget_commitment { po_id: string, amount_minor: int64, currency_code: char(3), status: enum }; (reference, product may differ).
System event	`POST /v1/purchase-orders { supplier_id, requisition_id, lines[{requisition_line_id, quantity, unit_price_minor, currency_code, delivery_date, ship_to_address}], cost_center_id } -> 201 { id, po_number, status, commitment_amount_minor, currency_code }; GET /v1/purchase-orders/{id}; POST /v1/purchase-orders/{id}/transmit -> 200; emits procurement.po_issued and procurement.budget_committed events; idempotent via external_id.`
Lifecycle state	`DRAFT -> APPROVED -> TRANSMITTED; terminal CANCELLED; guard: DRAFT→APPROVED blocked when budget commitment insufficient; TRANSMITTED→CANCELLED blocked when lines partially received; requisition transitions APPROVED→PO_ISSUED on first PO creation.`

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

Reference data model

`purchase_order` { id: string, po_number: string, requisition_id: string, supplier_id: string, entity_id: string, status: enum, transmission_method: enum, transmission_logged_at: timestamp, external_id: string }; `purchase_order_line` { id: string, po_id: string, requisition_line_id: string, quantity: int, unit_price_minor: int64, currency_code: char(3), delivery_date: date, cost_center_id: string }; `budget_commitment` { po_id: string, amount_minor: int64, currency_code: char(3), status: enum }; (reference, product may differ).

API and events

`POST /v1/purchase-orders` { supplier_id, requisition_id, lines[{requisition_line_id, quantity, unit_price_minor, currency_code, delivery_date, ship_to_address}], cost_center_id } -> 201 { id, po_number, status, commitment_amount_minor, currency_code }; `GET /v1/purchase-orders/{id}`; `POST /v1/purchase-orders/{id}/transmit` -> 200; emits `procurement.po_issued` and `procurement.budget_committed` events; idempotent via `external_id`.

State transitions

`DRAFT -> APPROVED -> TRANSMITTED`; terminal `CANCELLED`; guard: DRAFT→APPROVED blocked when budget commitment insufficient; TRANSMITTED→CANCELLED blocked when lines partially received; requisition transitions APPROVED→PO_ISSUED on first PO creation.

Common implementation traps.

Treating the workflow as data entry

If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.

Hiding exception logic

Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.

Posting without recovery design

Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.

Skipping evidence design

A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.

Where Rivane fits.

Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.

References and source basis.

These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.

Back to ERP use cases