Aydınlatma metni yükleniyor…
A B2B order-approval workflow is an auditable decision process that routes a purchase request to the right authority according to the requester's role, order value, budget, product class, company structure and exception conditions. A dependable system is more than Approve and Reject buttons. It defines who can decide under which conditions, what happens when the approver is unavailable, whether an earlier decision survives an order change, and which document revision can reach ERP.
This guide helps procurement, operations, finance and technology teams translate approval requirements into software scope. The “Kumsal approval decision envelope” and role–amount–approver–delegation–exception matrix are original planning tools developed for this article. The examples do not replace legal signing authority, company policy or accounting advice; the organisation must approve its real limits and responsibilities.
A request, basket, order and approval record are different objects
A purchase request expresses a need for goods or services. A basket is a working area for lines that have not yet become a decision. An order is the commercial document intended for a supplier or ERP. An approval record is a decision made with defined authority about a particular document revision. Treating them as one record creates ambiguity during change, cancellation and audit.
For example, an employee may prepare a ten-line request; a manager may return two lines for correction; procurement may divide the remaining eight between suppliers. If the system retains only “order approved”, nobody can establish which lines, amount and terms were accepted. Header data, lines, price revision, currency, tax, delivery address and attachments need to remain attached to the decision context.
Assign business ownership before designing the workflow
The portal should not invent company policy. Process owners must decide which lines procurement reviews, who owns each budget, when finance becomes mandatory, who validates technical items and who makes the final commercial decision. Software is the layer that applies and evidences that policy consistently.
Microsoft's procurement and sourcing workflow documentation treats requisitions and purchase orders as separate review and approval workflows, and allows participants to be selected through roles, organisational hierarchy, queues or named users. The broader design lesson is useful beyond one product: an “approver” is not merely a fixed email address, but a responsibility calculated from the document and organisation.
The Kumsal approval decision envelope
When someone approves a request, retain the context as well as the outcome. The Kumsal approval decision envelope keeps eight elements together:
- Document identity and revision: The exact request or order revision covered by the decision.
- Decision scope: The whole document, selected lines or only a budget check.
- Rule revision: The policy and threshold table that selected the approver.
- Authority context: Role, company, branch, cost centre and active delegation.
- Calculation inputs: Currency, exchange rate, total, product class and budget impact.
- Outcome: Approve, reject, request change, partial approval, reassign or cancel.
- Reason and evidence: Required comment, attachment, timestamp and secure event record.
- Next state: Next approver, waiting window, ERP transfer or correction task.
This envelope answers a more valuable question than “who approved?”: “Which exact document revision did the person approve, under what authority and calculation inputs?”
Build a role–amount–approver–delegation–exception matrix
Turn the approval policy into a testable decision table rather than leaving it in an email thread. Replace the illustrative entries below with the organisation's actual roles and thresholds.
| Condition | Decision owner | Delegate/fallback | Exception | Required evidence |
|---|---|---|---|---|
| Role is within its spending authority | Budget owner or automatic policy | Registered delegate | Restricted item, budget overrun or off-contract supplier | Limit, budget and rule revision |
| Document exceeds the threshold | Next financial authority | Department approval queue | Inactive approver or conflict of interest | Calculated total and hierarchy path |
| Controlled product or service | Technical/compliance owner | Specialist group | Missing evidence or expired certificate | Line scope and attachments |
| Off-contract price or supplier | Procurement manager | Supplier-review queue | Documented urgent purchase | Bid comparison and reason |
| Multi-company or cross-branch transaction | Authority for the relevant legal entity | Company-specific delegate | Wrong entity, cost centre or currency | Company, branch and accounting context |
Amount alone is rarely enough. The same value may need a different route because of product class, project, cost centre, supplier risk, urgency, contract status or available budget. Include the “no rule matched” condition and deny unauthorised progression by default.
Should approvals be sequential, parallel or first-response?
In a sequential workflow, the second authority cannot act before the first step finishes. This suits dependent decisions such as budget ownership followed by finance review. Parallel approval can begin technical, financial and commercial reviews together, but completion must mean all, a defined majority or a specified set of mandatory roles. First-response routing can help one member of an equivalent duty group claim a task; it should not allow unlike responsibilities to substitute for one another.
Microsoft's sequential approval documentation illustrates a second level beginning only after the first approves and records a product limitation against assigning the same approver to different steps. In any implementation, test ordering, completion conditions, one person holding several roles and duties that must remain separated.
Delegation, absence and timeout belong in the main design
An absent approver should not share an account. Delegation should be its own record with a start and end time, scope, delegator, delegate, authority ceiling and creation/approval evidence. It should expire automatically while preserving whether a historical decision used primary or delegated authority.
A timeout should not silently promote every request to senior management. The system may remind, move to a fallback queue, escalate to an authorised role or expose the delay to the requester. No escalation should exceed the new approver's actual authority. Microsoft's purchase-order approval example also presents approve, reject, request change and delegate as distinct actions.
Re-evaluate approval when the document changes
Quantity, price, discount, delivery address, supplier, payment term or order lines may change after approval. Invalidating every decision for every edit causes unnecessary delay; retaining every decision can let an unapproved order proceed.
Classify changes. A typographical correction with no commercial effect may preserve an approval. An increased total, new product, changed currency or changed legal entity should invalidate the relevant decisions. Show the difference between revisions and retain why each approval was requested again.
Design partial and line-level approval deliberately
One order may contain office supplies, software licences, equipment and controlled items. Sending everything to one person can create unnecessary access and delay. Line routing can place each class with the right specialist, but the design must state whether the order can split, how shared discounts or freight change, and which revision owns the remaining lines.
Microsoft's purchase-requisition workflow documentation describes routing either the whole document or individual lines, with all line reviews completing before the overall process can finish. Line-level approval is therefore a document-integrity decision, not merely a user-interface option.
Do not leave authorisation to interface buttons
Hiding an approval button does not prevent an unauthorised transaction. The server should re-evaluate the user's current role, company and branch scope, document state, revision, amount and delegation on every request. Direct API calls, stale browser tabs and modified requests must meet the same policy.
The OWASP Authorization Cheat Sheet recommends least privilege, deny by default and permission checks on every request. For approval workflows this goes beyond “has approver role”: the user needs authority over this specific document, in this state and at this amount.
Send only a complete and immutable decision package to ERP
When the portal reaches Approved, an order number alone may be insufficient for ERP. Transfer the document revision, lines, price and tax totals, currency, company and cost centre, approval summary and a unique transfer identifier. Retrying the same transfer must not create a second order.
An ERP rejection is not the same as a business rejection. An invalid cost centre needs data correction; a budget owner's rejection needs a new business decision. The exception queue should retain the stage, safe error summary, owner and replay behaviour. Use the ecommerce–ERP integration guide for complementary data-ownership and retry scope.
Derive acceptance tests from boundary conditions
| Scenario | Expected decision | Evidence |
|---|---|---|
| Total is one minor unit below and above the threshold | Correct threshold and approver are selected | Rule revision, inputs and route |
| Approver is absent; valid delegate exists | Only the delegated scope moves to that person | Delegation period and scope |
| Price increases after approval | Affected decision becomes invalid | Revision diff and reapproval reason |
| Requester and approver are the same user | Separation of duties applies when policy requires it | Block or alternative route |
| Two approvers act simultaneously | Only the first valid action persists; the other sees the current state | Decision time and revision check |
| Connection drops before ERP response | Safe retry uses the same transfer identifier | One ERP order and event history |
| No rule matches | Default deny or visible review queue | No unowned request |
Do not measure success by approval time alone
Mean decision time can be useful, but it is not proof of better governance. Track first-time correct routing, overdue tasks, delegated decisions, approvals reopened after a change, exception age, unauthorised attempts, ERP rejects and requests that become valid orders.
Define the denominator and clock. Does “approval time” end at the first decision, all mandatory decisions or ERP acceptance? Are business hours and holidays excluded? Without those definitions, departments or reporting periods cannot be compared responsibly.
What should an implementation proposal deliver?
- Role, company, branch, cost-centre and data-scope matrix
- Amount, budget, product, supplier and exception decision table
- Sequential and parallel steps with completion conditions
- Delegation, absence, timeout, escalation and conflict rules
- Document revision, change and reapproval policy
- Partial and line-level decisions plus order-splitting behaviour
- ERP fields, duplicate-transaction protection and exception queue
- Audit history, notifications, reports and retention permissions
- Acceptance-test matrix built around real boundary conditions
For the wider role, data and integration layers, use our enterprise portal planning guide.
Conclusion: approval starts with decision policy, not buttons
A sound B2B workflow sends the right document revision to the right authority through an explainable rule. It treats delegation, exceptions, changes, safe retries and ERP delivery with the same care as the happy path. To scope roles, limits, approvals and integration around your organisation, explore Kumsal Agency web-development services.