The hardest part of a Sage Intacct purchasing implementation is not the software. It is the meeting where finance wants every order approved and operations wants to order a replacement part before the crew loses a day. Both positions are reasonable. The approval chain you design is the answer to that argument, and it is worth more thought than the configuration takes.
Get it wrong in the strict direction and people route around the system, raising orders after the fact so the purchase order becomes a receipt with extra steps. Get it wrong in the loose direction and you have committed spend nobody approved. Most of the projects we are called into to repair are one of those two, and both are design problems rather than software problems.
Key Takeaways
- Purchasing is a separate module from accounts payable. It adds requisitions, purchase orders, receiving and matching in front of the bill.
- The approval matrix is the whole project. Design it around thresholds and roles, not around named individuals or the current org chart.
- Committed spend becomes visible at the order, not the invoice, which is the change budget owners notice first.
- Receiving discipline decides whether three-way matching helps or hinders. If nobody records receipt, matching just creates exceptions.
- Purchasing and accounts payable should be implemented together. Retrofitting orders onto a live AP process means training the same people twice.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What Sage Intacct purchasing actually covers
Purchasing handles everything upstream of the vendor bill: requisitions raised by staff, approval routing, purchase orders issued to vendors, receiving against those orders, and matching the invoice back to both. It shares vendors, dimensions and the ledger with accounts payable rather than sitting beside them as a separate system.
The map above is a fair picture of the scope. The top row is master data you have to get right before anything works: vendors, warehouses, product lines, items and price lists. The middle row is the daily work. The bottom row is reporting. Most implementation effort lands on the top row, which surprises people who expected the effort to be in workflow design.
What procurement software means in practice is the enforcement of a sequence. A requisition cannot become an order without approval; an order cannot become a payable without a match. That sequence is the control. Everything else is convenience.
The procurement cycle, document by document
A requisition is a request. A purchase order is a commitment to a vendor. A receipt records what actually arrived. A vendor invoice is the demand for payment. Each converts into the next, carrying its coding and dimension values forward, so nothing is re-keyed and each document can be traced in both directions.
All of these documents are built from the same underlying transaction framework, which is why the entry screens look alike whichever end of the chain you are working at. That consistency has a practical benefit during rollout: someone trained on one document type is most of the way to understanding the others, and the customisation you apply to one (extra fields, different numbering, a different approval path) works the same way on the rest.
The conversion step is where the value sits. When a purchase order becomes a vendor invoice, the amounts, the account coding and the dimension tags come with it. The AP clerk is checking rather than typing. If the invoice disagrees with the order or the receipt, the system flags it rather than quietly accepting whatever the vendor sent. That single behaviour catches more money than most of the reporting features people buy the system for.
Designing an approval chain finance and operations both accept
Approval rules route a document to the right people based on amount, entity, department, location, vendor, item category or account. They can require several approvers, escalate on inactivity, and differ by document type. The design question is not what is possible. It is what people will actually use.
Three principles hold up across most implementations. First, set thresholds so that the large majority of transactions clear in one step. If a department head is approving forty low-value orders a week, they will stop reading them, and an approval nobody reads is a control that exists only on paper. Second, route by role rather than by name. People change jobs; a matrix full of individuals needs maintenance nobody has scheduled. Third, keep the whole matrix short enough that a new finance manager can read it in ten minutes. Long matrices are usually a sign that exceptions have been encoded rather than decided.
Budget checking is the piece that most changes the tone of the finance and operations conversation. When an order can be checked against the remaining budget for that department or project at the moment it is raised, the argument stops being about trust and becomes about numbers on a screen. It also moves the conversation earlier, which is the whole point.
[DATA: Lucentive’s typical requisition-to-purchase-order cycle time before and after implementation — Rich to confirm]
Faster, smarter purchasing: where the speed comes from
Speed comes from three unglamorous places: templates for repeat orders, price lists that populate cost automatically, and approval that happens on a phone. None of them is a headline feature and together they account for most of the cycle time reduction teams report.
Repeat purchasing is a bigger share of volume than most organisations realise. Once the frequently ordered items are on the item master with agreed pricing, raising a requisition becomes selection rather than description, and the errors that come from free-text descriptions disappear with it. That is also what makes spend analysis possible later, because consistent item records are what let you see that four sites are buying the same thing from three vendors at three prices.
Mobile and email approval matters more than it sounds. The bottleneck in almost every purchasing process is an approver who is not at a desk. Removing that constraint takes days out of the cycle without changing a single rule.
Seeing the entire purchase management process
Because orders, receipts and invoices share the ledger, committed spend appears in reporting the moment an order is approved rather than when the invoice arrives weeks later. Budget owners see what they have committed, not just what has been billed, and finance sees the gap between the two.
In practice this shows up as a dashboard with the approval queue, vendor aging and spend against budget on one screen. The operational habit it creates is the valuable part. A department head who can see committed spend stops asking finance where they stand and starts managing to a number, which is a different working relationship from the one most finance teams have before implementation.
The reporting also answers the questions that justify the module to a board: what did we spend with each vendor, how much is committed but not yet invoiced, which purchases bypassed the process, and where are the same goods being bought at different prices. Those are hard questions to answer from a filing cabinet and straightforward ones to answer from an order history. It is the same visibility principle we describe in our manufacturing and distribution client work.
Where purchasing implementations get stuck
Purchasing projects rarely fail on configuration. They fail on master data that was never cleaned, an approval matrix that grew during design, receiving that nobody owns, and operational users who first heard about the change at training. Each is easier to prevent in week two than to fix in month six.
Item master versus free text
Deciding what belongs on the item master is genuinely difficult and it stalls projects. Too few items and everything is typed free-hand, which kills spend analysis. Too many and maintenance becomes a job nobody owns. The workable rule is to catalogue what you buy repeatedly and allow free text for the rest, then review quarterly.
Over-engineering the approval matrix
Every exception someone remembers wants to become a rule. Resist it during design. Start deliberately simpler than feels comfortable, run a quarter, then add the rules the exceptions actually justified.
Receiving discipline
Three-way matching only works if somebody records the receipt. In organisations where goods arrive at sites without an office, this is a real operational change and it needs an owner, a device and training. If you cannot solve receiving, use two-way matching honestly rather than three-way matching badly.
Treating it as a finance project
Purchasing is the module where the users are mostly not in finance. If operations is not represented in design sessions, adoption fails after go-live and the workaround is retrospective orders. Put the loudest operational sceptic on the design team.
The retired page answered the same worry with a customer story rather than a method: a director of accounting who had outgrown QuickBooks, evaluated NetSuite alongside Sage Intacct and chose Sage on interface and price. It is a real quote from a real finance leader, and it is evidence about the product. It says nothing about who sat in the design sessions, whether operations was represented, or what that organisation’s approval matrix looks like on a Tuesday morning. Those are the questions that decide whether your own rollout lands, and no vendor reference can answer them for you.
Summary
Purchasing gives you control at the point of commitment rather than at the point of payment, and that is a genuine change in how an organisation spends money. The software part is quick. The work is master data, an approval matrix short enough to be read, receiving discipline, and getting operations into the room before anything is configured.
[DATA: Lucentive’s typical implementation timeline for the purchasing module alongside accounts payable — Rich to confirm]
Alongside that customer story, the page this replaces offered a datasheet and a white paper behind a form. Useful background, but none of it answers the question you actually have, which is what your approval matrix should look like given how your organisation really buys. Bring us a month of your purchase requests and we will map it with you. Start with a conversation with our team, or read the wider case in the benefits of a purchase order system.
Frequently Asked Questions
What is the difference between a purchase requisition and a purchase order?
A requisition is an internal request to buy something, raised by whoever needs it and routed for approval. A purchase order is the approved external commitment sent to the vendor. Some organisations only need purchase orders, typically where the same small group both requests and approves. Requisitions earn their place when the people who need things and the people who authorise spending are different.
Do we need the purchasing module, or can we manage orders in accounts payable?
Accounts payable handles the bill. It does not create orders, record receipts or perform matching. If you want control before money is committed, or committed-spend visibility against budget, you need purchasing. If your controls are adequate at the invoice stage and volumes are low, accounts payable alone may be enough. Our guide to accounts payable automation covers that side.
What does procurement software actually do?
It enforces a sequence and records it. A request is approved before it becomes an order, an order is matched against what arrived before it becomes a payable, and every step is timestamped against a person. Around that core sit conveniences such as catalogues, price lists and templates. The control is the sequence; everything else makes the sequence tolerable to use.
Can it replace a purchase order tool bolted onto QuickBooks?
Usually yes, and the gain is that orders, receipts, invoices and the ledger stop being separate systems that need reconciling. Bolt-on purchase order tools work until the volume of exceptions outgrows the integration between them. If you are already maintaining a spreadsheet to reconcile your purchase order tool to your accounting system, that is the signal.
Does budget checking stop a purchase order?
That is configurable, and the choice matters. It can warn and allow, warn and route for additional approval, or block outright. Blocking is appropriate for grant-funded and project-funded work where overspend is not recoverable. A warning with escalation usually works better for general operating budgets, because a hard block on a routine order tends to produce a workaround.
How does purchasing connect to order processing on the sales side?
They are separate modules that mirror each other, one running vendor-facing documents and one running customer-facing documents, both posting to the same ledger and dimensions. Distributors and manufacturers usually implement both so that inventory, committed purchases and sales commitments reconcile. Our explainer on what order processing involves covers the sales-side chain.