A procurement system is the software that carries a purchase from the moment someone recognises a need to the moment the supplier gets paid. That is the whole definition. Everything else is a question of how many of those steps a given product covers, and how well it hands work to the step next door.
The confusion around the term comes from the fact that the market sells the same territory under at least four names. Source to pay, procure to pay, e-procurement, and spend management all describe overlapping slices of one process. Understanding where the boundaries sit is the difference between buying a tool that fits the gap you actually have and buying one that duplicates what your ERP already does.
The stages of the process
The full cycle is conventionally split into two halves.
The upstream half, sometimes called source to contract, is about deciding who you buy from and on what terms:
- Spend analysis. Classifying historical spend so you can see what you actually buy, from whom, and at what price. Without this the rest is guesswork.
- Sourcing. Running the RFI, RFP, or RFQ that puts a requirement in front of candidate suppliers, and comparing what comes back.
- Contract management. Recording the agreed terms, prices, and durations in a form the downstream systems can read.
- Supplier management. Onboarding, qualifying, and monitoring the suppliers you have decided to work with.
The downstream half, procure to pay, is about executing against those decisions, over and over, at volume:
- Requisition. An employee states what they need. This is an internal request, not yet an order.
- Approval. The request passes through whatever policy the organisation has set: budget owner, cost centre, spend threshold.
- Purchase order. The approved requisition becomes a legal commitment sent to the supplier.
- Receipt. Someone confirms that the goods or services arrived.
- Invoice. The supplier bills for what was delivered.
- Matching and payment. The invoice is reconciled against the order and the receipt, then released to accounts payable.
Most organisations run far more transactions through the downstream half than the upstream half. A sourcing event might happen once a year for a given category. A requisition against the resulting contract might happen four hundred times in that same year.
What the acronyms actually mean
S2P (source to pay) covers both halves. A true S2P suite handles sourcing and contracting as well as ordering and invoicing. Ariba, Coupa, Jaggaer, and Ivalua sit in this space.
P2P (procure to pay) covers only the downstream half: requisition through payment. This is the highest-volume, most operational part of the process, and it is where most of the measurable savings leak away.
E-procurement is an older and looser term. In practice it usually means the ordering and catalogue portion of P2P, the part employees interact with directly.
Spend management is a marketing category more than a technical one. It typically means S2P plus expenses, and sometimes plus treasury or budgeting.
The practical consequence: when a vendor says they do procurement, ask which stages. A tool that does brilliant sourcing analytics and nothing downstream will not reduce the number of invoices your AP team keys by hand.
Where the ERP fits
Nearly every organisation already owns something that does part of this. SAP, Oracle, NetSuite, Microsoft Dynamics, and their peers all ship purchasing modules. They generate purchase orders, they record goods receipts, they post invoices to the ledger.
What ERP purchasing modules are historically weaker at is the employee-facing part: a shopping experience an occasional user can navigate without training, catalogue content that stays current, and supplier connectivity that does not require a bespoke integration project per supplier. That gap is why the dedicated procurement market exists at all.
The design question for any organisation is therefore not “ERP or procurement system” but “which system owns which record”. The ledger almost always stays in the ERP. The question is whether the requisition, the catalogue, and the supplier relationship live there too, or in a layer above. We work through a specific version of this boundary problem, in a hospitality context, in our piece on whether the PMS or the P2P stack should be the system of record.
The catalogue is the load-bearing part
If you look at where procurement systems succeed or fail in practice, the answer is rarely the workflow engine. Approval routing is a solved problem. The failure mode is almost always content.
A requisition can be raised in two ways. The employee can pick an item from a catalogue, in which case the description, the part number, the price, the unit of measure, and the supplier are all correct by construction. Or the employee can type a free-text description of what they want, in which case every one of those fields becomes a guess that someone downstream has to fix.
Free-text requisitions are where maverick spend, price leakage, and invoice exceptions come from. The percentage of spend that flows through structured catalogue content, rather than free text, is the single most useful health metric for a procurement system. We go deeper into what a procurement catalog is and the forms it takes, and into why keeping catalogue content clean is so much harder than it looks.
How suppliers connect
A procurement system is only as good as the supplier connections behind it. There are broadly three patterns.
Static catalogue upload. The supplier sends a file, typically CIF, BMEcat, or a spreadsheet, and the buyer loads it. Simple, universally supported, and stale the moment prices change.
PunchOut. The employee clicks through from the procurement system into the supplier’s own web store, shops there with contract pricing applied, and the cart is returned into the requisition. The supplier maintains the content, so it never goes stale. We explain the mechanics of the PunchOut round trip separately, along with the cXML protocol underneath it.
Direct integration. API or EDI connections that exchange orders, confirmations, dispatch advices, and invoices as structured messages. The highest fidelity and the highest setup cost per supplier.
Most real estates run all three at once, weighted by supplier size. The large distributors get integration. The mid-tier gets PunchOut. The long tail gets a file, or nothing.
What good looks like
A procurement system is working when four things are true at once. Employees can find what they need without calling anyone. The price on the requisition matches the price on the invoice. The receipt exists before the invoice is paid. And adding a new supplier does not require an integration project.
Those four conditions sound modest. In practice, most estates fail at least two of them, and the failure is usually traceable back to catalogue content or supplier connectivity rather than to the workflow layer everyone spends their evaluation time on.
That is the part BoreaTech works on. Our product, SupplierForge, focuses on the connectivity and catalogue layer specifically: getting supplier content into a buyer’s existing procurement system in a form that stays accurate, without a separate integration project for every supplier. We are deliberately not trying to replace the ERP or the approval workflow you already have.