Design purchase approvals around delegated authority and exceptions
For Procurement head / materials manager · Plan implementation
TL;DR — what you’ll learn
- Configure approved authority by category, scope, value and effective delegation.
- Bind an approval to the version of the request that was reviewed.
- Treat changed quantities, expired delegation and uncertain ERP results as explicit exceptions.
- Start with one purchase category and prove that replay cannot create another order.
A requester increases a purchase quantity after approval. The workflow retains its green approval badge and sends the larger order to the supplier. The automation has used a valid decision for a transaction the approver never saw.
This proposed workflow implements an authority model supplied by the hospital; it does not define purchase limits or grant approval rights. Use synthetic request versions to test whether each demonstrated order can be traced to the corresponding authorised decision.
Define the first pilot precisely
Use one hospital site, one routine purchase category and one named procurement owner. Exclude clinical product substitution, emergency exceptions and new supplier bank-detail changes from the initial automated path unless their controls are explicitly designed and approved.
The pilot needs request ID and version, site, category, item, unit, quantity, value basis, requester, technical-review reference, required approver, delegation scope and expiry, decision timestamp and final PO reference. Store the rule version that selected the approver so the decision remains explainable after policy changes.
Quantbit describes configurable approval routing. The implementation question is whether the proposed configuration reproduces this hospital's actual delegation and amendment rules, not whether it can display a multistep workflow.
Revisit the decision when the request changes
In the illustrative case, request R-31 version 1 asks for 50 boxes. Version 2 asks for 80. Preserve the first decision against version 1, mark it superseded for the changed request and apply the agreed reapproval rule. Do not delete the earlier history.
Scroll horizontally to see all columns.
| Challenge | Required result in the proposed pilot |
|---|---|
| Quantity or commercial scope changes | Version change and appropriate reapproval |
| Delegate's authority expires | Pending request routes through a valid authority path |
| Requester tries to approve own request | Enforce the approved separation rule |
| Orders appear split to avoid review | Flag for procurement review under approved policy |
| The same approved request is sent twice | One final PO or an owned uncertainty requiring reconciliation |
Which changes require reapproval and which roles must be separate are provider-specific governance decisions. Do not copy thresholds or emergency rules from a vendor's example.
Separate routing from the power to approve
The service account can create a review task and notify an approver. It should be allowed to issue or create a PO only after the approved conditions are satisfied and only within its configured scope. Keep credentials out of request documents and validate permissions on the server handling the action.
An AI extractor can propose category and quantity from a request attachment. The requester or reviewer must resolve uncertainty before those fields determine authority. A line in a document saying “already approved” is not an authenticated approval event.
Worked workflow
Original illustrative workflow. Follow the labelled transitions, including the exception paths.
- A · StepVersioned request
- B · StepApply approved authority rules
- C · DecisionValid review and approval complete
- D · StepOwned pending or exception task
- E · DecisionRequest version still matches
- F · StepCreate PO with stable request reference
- G · DecisionERP outcome known
- H · StepReconcile before retry
- I · StepRecord one PO reference
Scroll horizontally to see all columns.
| From | Condition | Next |
|---|---|---|
| A: Versioned request | Continue | B: Apply approved authority rules |
| B: Apply approved authority rules | Continue | C: Valid review and approval complete |
| C: Valid review and approval complete | No | D: Owned pending or exception task |
| C: Valid review and approval complete | Yes | E: Request version still matches |
| E: Request version still matches | No | A: Versioned request |
| E: Request version still matches | Yes | F: Create PO with stable request reference |
| F: Create PO with stable request reference | Continue | G: ERP outcome known |
| G: ERP outcome known | No | H: Reconcile before retry |
| G: ERP outcome known | Yes | I: Record one PO reference |
The final version check prevents an old approval being applied to a request edited while the creation job was queued.
Recover without issuing a second order
Before allowing order creation, obtain the ERP’s documented creation, lookup and duplicate-handling behaviour. Test a lost response against a stable request/version reference. If the existing result cannot be established safely, retain an uncertain outcome for review rather than blindly creating a second order.
If the interface is unavailable, pause automated creation and use the authorised manual procedure. Capture any manually created PO reference before resuming, so queued work can be reconciled. Rollback means disabling the new route and returning to an agreed procedure; it does not mean deleting orders already communicated to suppliers.
Run a synthetic challenge set with changed quantities, invalid delegation, duplicate submissions, denied permissions and a lost ERP response. Require no unapproved or duplicate POs in that test set, and require every uncertain case to have an owner. Record approval age and re-entry effort against a baseline from the same scope. These are acceptance tests, not a guarantee about every future transaction.
Collect evidence at the last approval boundary
Make the acceptance record show which decision authorised the attempted write. For R-31, retain the request version, rule version, approver decision, delegation reference and resulting PO identity. Agree with the governance owner whether a later delegation change affects an already-made decision or only future approvals; the integration must not invent that interpretation.
Scroll horizontally to see all columns.
| Synthetic challenge | Expected observable result | Evidence retained |
|---|---|---|
| Version 2 replaces approved version 1 | No PO created from the superseded approval | Both request versions and new review task |
| Two workers process the same approved version | One accepted PO outcome | Stable request reference and destination lookup |
| ERP accepts but response is lost | Case stays uncertain until reconciliation | Attempt record, lookup result and final PO ID |
| Staff create an authorised manual PO during outage | Queued automation does not create another | Manual PO linked to the original request |
The procurement owner reviews the decision trail; the ERP owner verifies the destination records. Begin with shadow routing that creates no orders, then consider a limited write stage only after the challenge set passes and the owners approve it. Stop the write stage if an accepted order cannot be traced to the approved version. The scope is approval-to-PO creation; subsequent invoice matching requires its own evidence and authority.
This final evidence trail is what makes the approval workflow reviewable after the event. A green badge or a fast notification is insufficient if the hospital cannot identify the version and authority behind the order.
Next actions
- Approve one category's authority, delegation and amendment rules.
- Verify ERP creation, lookup and recovery behaviour in a test environment.
- Run the challenge set and agree the manual fallback before permitting production writes.
Discuss this workflow
Discuss a purchase-approval pilot for one category, including delegated authority, request changes and recovery after uncertain ERP responses.
Describe the operation using business information only. Please leave out patient details.
Applying this guide
The scenarios and numbers are illustrative. Confirm these provider-specific inputs before implementation:
- Procurement head, finance approver and internal audit: Signed delegation matrix, amendment rules and emergency-policy boundaries; no borrowed vendor thresholds.
- ERP owner and integration architect: Versioned interface evidence and challenge tests for changed requests, lost responses, manual orders and duplicate submissions.
References
- Quantbit HISx procurement — Advertised routing and partial-receipt capabilities; no adoption of vendor outcomes, thresholds or compliance claims.
Topics: hospital purchase approval workflow · hospital PO approval · hospital indent approval · purchase approval automation healthcare