MYOB Acumatica Purchase Requisitions and Approvals: Controlling Spend Before the Purchase Order

MYOB Acumatica controls buying in two layers. The Purchase Requisitions feature turns employee or customer requests (form RQ301000) into requisitions (RQ302000) with budget checks and vendor bidding before any purchase order exists. The Approval Workflow feature then routes requests, requisitions and purchase orders through approval maps, so a purchase order sits at Pending Approval until the right person signs it off, and receipts are created only against Open orders.

At a glance

• Who it is for: Australian wholesale distributors and multi-site businesses on MYOB Acumatica (called MYOB Advanced until 2024) where more than one person raises purchases and finance wants to see spend before it is committed, not when the bill arrives
• Problem it solves: Purchase orders raised by email or phone, committed to a supplier before anyone has checked budget, vendor or price, and matched to the bill after the fact
• Platforms: MYOB Acumatica, all editions; Purchase Requisitions and Approval Workflow are features switched on from the Enable/Disable Features form (CS100000), not separate products
• Typical cost: MYOB publishes no separate price for either feature; licensing is per named user and quoted through partners, and the configuration sits inside implementation scope. Our MYOB Acumatica cost guide gives the indicative implementation ranges
• Typical timeline: Purchase orders are inside the 12-week MYOB FastStart for wholesale distribution scope; approval maps and requisition classes are configuration on the preference forms, not customisation
• Last verified: 19 October 2026 against MYOB’s purchase requests and requisitions guide, approval configuration guide and purchase order statuses reference

Most distributors we meet have a purchasing control that lives in one person’s inbox. The buyer emails the supplier, the finance manager finds out when the bill lands, and the “approval” is whether anyone objects at month end. MYOB’s 2025 ERP trends report found that 45% of decision-makers say siloed systems limit growth, and purchasing is where the silo costs real money: a committed order is a committed cost. This guide covers the two features MYOB Acumatica gives you to put the control before the commitment, what each form does, and the settings that trip people up.

What is the difference between a request, a requisition and a purchase order in MYOB Acumatica?

Three documents, three jobs, and MYOB’s purchase requests and requisitions guide draws the lines clearly.

• A purchase request (RQ301000) is a list of the stock items one person wants. It belongs to that requester. Requests come in two kinds, set by the request class: employee requests for internal use, which can carry approval and budget validation, and customer requests for items you will later sell to that customer.
• A purchase requisition (RQ302000) is the buyer’s working document. It gathers the items, picks the vendors, optionally runs bidding, and is the document that creates orders. One requisition can be built from many requests through the Create Requisitions form (RQ504000), and lines for the same item, requester, estimated cost and expense account can be merged.
• A purchase order (PO301000) is the commitment to the supplier. Clicking Create Orders on the requisition creates one purchase order per selected vendor and sets the requisition to Released. For customer requests the same action also creates the sales order, with each line marked for PO and linked to the purchase order line, so a back-to-back sale is wired up in one step.

The requisition layer is optional. Plenty of sites run purchase orders with approval maps and never switch on Purchase Requisitions. You want the requisition layer when buying is initiated by people who should not be raising purchase orders (branch staff, project managers, sales reps ordering for a customer), when you want vendor bidding on larger buys, or when you want a budget check before the order exists rather than after the bill does.

How do requisitions, budgets and vendor bidding fit together?

The configuration guide describes a short setup: enable the feature, create request classes, set the preferences, and optionally wire in budgets.

Request classes (RQ201000) carry the rules for a type of request: a promised lead time in days, whether multiple vendors may be suggested for one request, whether requesters are restricted to a listed set of items, and the budget validation level. That last setting is the one distributors underuse. Set to None by default, it can be Warning or Error against an expense account, and the Budget tab of the request shows whether the requested items fit the budget released on the Budgets form (GL302010). If they do not, the guide gives you three options: trim the items, reject the request, or process it in the next financial period.

Preferences (RQ101000) set numbering, how many months requests and requisitions are kept, the assignment map used for approval (which must exist first), whether lines merge by default, and whether a purchase order created from a requisition starts On Hold. We switch that last one on for sites where the buyer wants a final read of the PO before it moves into the approval or printing queue.

Bidding is the part most buyers do not know they have. Vendors are added to the Bidding tab of the requisition, requests for proposal go out to all of them or one at a time, responses are keyed on the Bidding Responses form (RQ303000), and the Complete Bidding form (RQ503000) picks vendors by offered price within quantity limits. The guide notes that the manual Select Vendor action on the requisition itself allows only one vendor per requisition, so a split buy goes through the bidding forms, not the shortcut.

One release-level detail worth knowing: MYOB’s 2026.1.1 release notes state that if a purchase order created from a requisition is deleted, the requisition returns to Open and Create Orders becomes available again, creating a new purchase order for each vendor that has none. Check your site is on that release before you rely on it.

How do approval maps work in MYOB Acumatica?

Approvals are a platform feature, not a purchasing one. Switch on Approval Workflow at CS100000, and MYOB’s approval configuration guide lists the document types you can then approve: purchase orders, requests and requisitions, AP bills and payments, sales orders, expense claims, journal transactions, projects and more. Each type has its own approval map, built on the Approval Maps form (EP205015), and the guide is explicit that a map does nothing until it is selected on the matching preferences form.

An approval map is steps containing rules. Each step and rule has a table of conditions on fields of the document, with operators including Equals, Is Greater Than, Is Less Than, Is Between, Contains and Is Empty, and brackets to control evaluation order. The approver for a rule can be a named employee, an employee read from a field on the document, employees selected by a filter, or a workgroup from the company tree, in which case anyone in that workgroup or a higher one can approve.

Three settings decide how the map behaves, and they are the ones to get right in the design workshop.

• On Approval. Collect All Approvals from This Step waits for every assigned approver; Complete Step moves to the next step as soon as one approver acts; Approve Document approves the record outright and skips the remaining steps. MYOB’s parallel and multistage guide describes parallel approval as one step, one rule, all approvers listed, Collect All selected, and multistage approval as several steps where, in its example, “if at least one accountant approves the transaction at the first stage, the approval progresses to the next stage”.
• Decision Wait Time. How long an approver has to act. The documentation states that a zero wait time means the record “may await approval for an indefinite period”, which is exactly what happens to the PO raised the day the warehouse manager went on leave.
• Reasons. Approval and rejection reasons can be Is Not Prompted (the default), Is Optional or Is Required. If a reason is required, the approver must work from the document itself, not the Approvals list (EP503010), and if a rejection with a reason is returned for editing, every other approval on the record is cleared.

Notifications are optional email templates (SM204003). The guide notes that “authorized users can approve and reject records regardless of whether they receive notifications”, so the approvals list, not the inbox, is the system of record.

Can MYOB Acumatica stop a purchase order being sent before it is approved?

Yes, by status. MYOB’s purchase order statuses reference sets out the path a controlled order takes, and the table below is the version we walk buyers through.

The mechanics live on the Purchase Orders Preferences form (PO101000): tick Require Approval on the Approvals tab, then add a row per order type with its approval map and, optionally, a pending approval notification template. Two things from that page matter more than they look. First, approval is per order type, so a drop-ship order and a standard order can carry different maps, or none. Second, the warning on the form: if an order type has no map, “all new orders of this type will be automatically approved”. A site that enables approvals but forgets the drop-ship row has a hole in the fence exactly where the biggest orders go.

Receipts are the enforcement. Because the reference describes receipts as created against Open orders, goods cannot be receipted against an order that has not cleared approval, which is the control an auditor actually asks about. It also lines up with the ATO’s requirement that you hold a tax invoice to claim a GST credit on purchases over A$82.50 including GST: an approved PO, a receipt and a matched bill give you the paper trail in the order the ATO expects it.

“Every distributor says they have PO approval. What they usually have is one person who can see every PO. The difference shows up the week that person is away: the map keeps working, the inbox does not. Set a decision wait time and a second approver before you need either.”

Bill Alvarez, Practice Manager, Auboros

Where purchasing approvals go wrong

The configuration is not hard. The design is where sites get it wrong, and we see the same five patterns.

• A single threshold on order total. One rule, Is Greater Than, one approver. It catches the big order and waves through fifty small ones to the same vendor in a month. Add a rule on vendor or on the inventory account, or use requisitions with a budget check per expense account, so the pattern is visible, not just the outlier.
• Approvals built on job titles that are really people. The map names an employee rather than a workgroup. When that person leaves, every order of that type stalls at Pending Approval. Workgroups on the company tree exist for this, and the Employee from Document option lets a map route to an employee named on the document itself, such as its owner, without hard-coding a person.
• Zero wait time. The default. Nothing escalates, nothing times out, and the approvals list is the only place the stall is visible. Set a wait time and decide what happens when it expires.
• Approving the requisition and the purchase order. Two maps, two queues, the same person approving the same spend twice. Approve at one layer: the requisition where buying is initiated by non-buyers, the purchase order everywhere else.
• No link to replenishment. Automatic replenishment creates purchase orders too, and they follow the same map. If the map needs a human for every order, the reorder point logic you tuned is now gated by a manager’s inbox. Give replenishment orders their own order type and a lighter map, or a higher threshold.

What this looks like for an Australian distributor

A typical build for a wholesaler on MYOB Acumatica has four pieces. Branch staff raise employee requests against a request class restricted to a catalogue of consumables and stock items, with budget validation set to Warning against the branch expense account. The buyer consolidates requests into requisitions weekly, running bidding on anything over a threshold the finance manager sets. Purchase orders carry a two-step map: anyone in the purchasing workgroup for orders under the threshold, the purchasing lead plus the finance manager in parallel above it, with a decision wait time so a stalled order has a deadline rather than an indefinite wait. Replenishment orders use their own order type with a single approver.

When the goods arrive, the receipt is keyed against the Open order and the bill is matched to it; our MYOB Acumatica accounts payable guide covers that side. The same 2026.1.1 release notes add that an estimated purchase price variance is now calculated when a bill is saved, before release, so an approval map can be built on the variance as well as the total. If your team is already using an AI replenishment agent to draft orders, the approval map is the human gate those drafts pass through.

None of this is customisation. It is forms, preferences and maps, which is why it fits inside a fixed-scope implementation. We are a MYOB Acumatica partner in Brisbane and an approved Queensland partner for FastStart, and purchasing control is the part of the ERP for wholesale distribution in Australia conversation that pays for itself fastest, because the order that should not have been placed is the easiest cost to measure.

Goes well with

• MYOB Acumatica accounts payable: vendor bills, EFT payments and BAS-ready coding
• MYOB Acumatica replenishment: reorder points and safety stock for distributors
• MYOB Acumatica hidden costs: what the licence quote leaves out

Want purchasing approvals that keep working when the approver is on leave?

We design requisition classes and approval maps for distributors across Queensland, NSW and Victoria, on new MYOB Acumatica implementations and on live sites where the map was never finished. If you want a second pair of eyes on how your purchase orders get approved today, book a free consultation. We will tell you what to change and what to leave alone.