Procurement Requisition & Approval Workflow

Most NetSuite accounts begin with the simplest possible purchase control: a Supervisor field on the Employee record and one dollar limit. That arrangement survives until the second subsidiary is added, or until a department starts spending against a capital budget, or until someone decides that anything over a set amount needs both the controller and the CFO in sequence. At that point approvals quietly migrate into email. NetSuite stops being the system of record for the decision, and Finance only discovers the gap later: a purchase order was issued against a budget line that was already nearly consumed, the requester was never told why their request stalled for nine days, and there is no timestamped record of who agreed to what.

Native approval routing handles a supervisor chain and a threshold. It does not evaluate remaining budget before the commitment is created, it does not route capital spend differently from operating spend, it does not escalate when an approver is on annual leave, and it gives the requester almost no visibility into where a request is sitting.

What ECOSIRE builds

ECOSIRE builds a procurement requisition and approval layer inside your own NetSuite account using SuiteScript 2.1, SuiteFlow and custom records. It is not a hosted service, and no external system holds your data. Everything runs as scripts, workflows and custom record types deployed to your account, delivered as an SDF project and an unmanaged bundle that you own outright.

The build extends the standard Purchase Requisition and Purchase Order records rather than replacing them, so vendor bills, three-way matching, item receipts and GL impact continue to behave exactly as NetSuite intends. Approvers approve NetSuite transactions, not copies of them held somewhere else.

The approval matrix

Routing rules live in a custom record type rather than being hard-coded, so Finance can change a threshold without a code deployment. Each rule is keyed on subsidiary, department, class, location, expense category or custom segment, item type, and an amount band expressed in the subsidiary base currency. A rule resolves to an ordered list of approval steps, and each step names either a specific employee, a role, or a dynamic reference such as the requester's supervisor or the department owner.

A User Event script evaluates the matrix on beforeSubmit, stamps the resolved chain onto the requisition, and a SuiteFlow workflow drives state transitions from Pending Approval through each step to Approved or Rejected. Because the chain is stamped at submission, later edits to the matrix cannot silently rewrite the history of an in-flight request. An edit that moves the requisition into a different amount band re-evaluates the chain and records why it changed.

Budget and commitment checking

The part native NetSuite does not do is check the money before the commitment exists. ECOSIRE builds a commitment ledger: a custom record holding, per budget key (accounting period, account, department, class, location, subsidiary and optional custom segment), the approved-but-unbilled requisition and purchase order value. A SuiteQL query through the N/query module reads the NetSuite Budget record for the period, subtracts posted GL activity and the open commitment, and returns the remaining amount at the moment of approval.

Depending on your policy, an over-budget requisition can be hard-blocked, soft-blocked with a mandatory override reason captured, or routed to an additional approval step. The check re-runs at purchase order creation, because the gap between requisition approval and PO issue is exactly where budgets get overrun.

Requisition to purchase order

Once a requisition is fully approved, a scheduled or user-triggered script converts it into one or more Purchase Orders using N/record.transform, splitting by vendor, currency and receiving location, and carrying department, class, location, custom segments and project references through to the PO lines. Preferred vendor and last purchase price can be pulled from the Item record and its vendor sublist so the buyer is not re-keying. Where a negotiated agreement exists, the script points the line at the agreed price level rather than the item base price.

Approving from anywhere

Approvers receive an email built with the N/email module containing the requisition summary, line detail and a signed single-use link. That link resolves to a Suitelet approval screen that works in a phone browser. Approvers who live inside NetSuite get a dashboard portlet backed by a saved search showing everything waiting on them. A RESTlet is included for teams that want approvals surfaced in a chat tool or internal portal; it enforces the same permission and amount-band checks as the UI, so an approver cannot exceed their authority by calling the endpoint directly.

Delegation is a first-class record: an approver sets a delegate and a date range, and a scheduled Map/Reduce escalation script reroutes anything sitting past its service level, logging both the nominated and the acting approver.

Audit trail and reporting

Every decision writes an append-only custom record: who, when, from which step, the amount at the time, the budget remaining at the time, the comment, and whether an override was used. That record is what auditors ask for and what makes month-end explainable. Saved searches ship for approvals by age, requisitions by state, override usage by approver, budget consumption by department, and cycle time from submission to purchase order.

Who this is for

This suits NetSuite accounts where purchasing has outgrown a single-supervisor chain: multi-entity groups on OneWorld, manufacturers running capital and MRO spend on different rules, professional services firms buying against project budgets, and any organisation that has to show an auditor a clean, timestamped approval trail. If you have two approvers and no budget control requirement, native routing is enough, and we will tell you that on the call rather than sell you a build.

How delivery works

Nothing here is pre-built and nothing downloads instantly. The sequence is a scoping call where we walk your current requisition flow, chart of accounts, budget structure, subsidiaries and actual approval rules; a fixed written quote and scope covering exactly what will be built; the build itself, typically two to four weeks depending on the number of routing dimensions and whether budget checking is in scope; installation into your sandbox account first, where you test with your own data and your own approvers; then a production install during an agreed window, with the SDF project and bundle handed over. A defined support window follows go-live for defect fixes and configuration adjustments.

What this is not

It is not a replacement for NetSuite procurement, a hosted portal, or a per-user subscription. It is a customisation of your own account, built once to your rules, that you keep.