What Is a Purchase Requisition System — And When Should You Build One Custom?

A purchase requisition system is software that manages how employees request and approve purchases — from the initial request through approval tiers, vendor selection, and purchase order issuance. It replaces the email chain or paper form that most procurement workflows start with, and gives finance, procurement, and operations teams a single system of record for every spend decision in the company.

Most organisations run their procurement workflow on email and spreadsheets for longer than they should. The breaking point arrives when approval chains have more than three tiers, when the same vendor invoice gets flagged by three different departments for different reasons, or when an auditor asks for a full spend history and nobody can produce one without two weeks of manual reconstruction.

What does a purchase requisition system actually do?

A purchase requisition system handles five core functions: request capture, approval routing, budget validation, purchase order generation, and audit trail maintenance. Each function sounds straightforward in isolation. The complexity is in how they connect.

Request capture collects what is being requested, by whom, for which department, against which cost centre, and why. Approval routing sends that request through the correct chain of approvers based on spend amount, department, vendor type, or item category. Different purchase categories often require different approval paths — capital expenditure and operating expenditure rarely go through the same sign-off chain.

Budget validation checks the request against available budget in real time before routing it for approval — not after it has already been approved by three people. This is where most email-based systems fail: the budget check happens after the approval chain runs, which means rejections arrive late and create friction with the requester.

Purchase order generation converts approved requisitions into formal POs with the correct vendor details, payment terms, and line items. Audit trail maintenance keeps a timestamped record of every action — who requested, who approved, who modified, when, and why. That audit trail is the difference between a clean external audit and a painful one.

Why do email and spreadsheets break down as a procurement workflow?

Email-based procurement breaks down at the point where approval logic becomes conditional. A single approval chain with one tier works fine over email. Two tiers with a CC works. Three tiers with escalation rules, budget thresholds, and category-specific routing does not.

The four specific failure modes that drive companies to replace email-based procurement are:

• Approval visibility — requesters have no idea where their request is sitting in the chain. Procurement teams spend 30–40% of their time chasing status updates rather than processing approvals.
• Budget leakage — when the budget check is manual, approvers approve against their memory of the budget rather than the live figure. Over-budget purchases surface during month-end reconciliation, not before the PO goes out.
• Routing errors — a capital expenditure above a defined threshold that should have gone to the CFO gets approved by a department head because the email was sent to the wrong person. The rule existed in someone's head. It was not enforced by the system.
• Audit failure — when an auditor or regulator asks for evidence that a specific purchase was properly authorised, the answer requires searching email threads, cross-referencing spreadsheets, and hoping no one deleted the relevant chain. This is not a compliance posture that survives scrutiny.

SaaS purchase requisition tools vs custom-built: when does each make sense?

SaaS purchase requisition tools work well for organisations with standard procurement flows. The threshold for 'standard' is lower than most procurement teams assume when they start evaluating software.

SaaS tools — Procurify, Coupa, SAP Ariba at the enterprise end — are built for the median procurement process. They assume a relatively flat approval hierarchy, a vendor master that maps cleanly to your chart of accounts, and that your approval rules can be expressed as simple thresholds. When those assumptions hold, SaaS is the right answer. Implementation takes weeks, not months, and the per-seat cost is predictable.

Custom-built makes sense when the procurement logic itself is a business differentiator — or when the cost of bending your process to fit a SaaS tool exceeds the cost of building your own. The signals that you have crossed that line:

• Conditional multi-tier approval logic — your approval chain varies based on department, item category, amount, project code, and vendor classification simultaneously, not just amount alone
• Deep ERP integration — your procurement system needs to write data back into a custom or legacy ERP in real time, not via a nightly batch export
• Custom vendor qualification requirements — vendor onboarding includes compliance checks, document collection, or scoring logic that no SaaS tool supports out of the box
• Project-based procurement — purchases need to be tracked against project budgets, milestones, or site codes rather than static cost centres
• Regulated industry requirements — your audit trail, data residency, or approval evidence requirements go beyond what SaaS vendors will contractually commit to

The decision is not ideological — it is a cost comparison. SaaS tool at $40/user/month with 200 users is $96,000/year. If you are spending $50,000 annually in procurement team time working around the tool's limitations, the case for building starts to close.

Tejas Networks: 90% reduction in paper-based approvals

Tejas Networks is a publicly listed electronics and telecommunications equipment company. Their procurement process had grown into a multi-tiered approval workflow that ran almost entirely on paper forms, email, and manual tracking by the procurement team. The audit trail was reconstructed from archived emails. Approval status lived in a spreadsheet that was updated manually whenever someone remembered to update it.

The challenge was not simply replacing paper with a digital form. Tejas had specific approval rules based on purchase amount, procurement category, department, and vendor classification. Routing was conditional — a purchase above a defined capital threshold required a different chain than an operating expenditure of the same amount. A standard SaaS tool would have required Tejas to flatten their approval logic to fit the tool. That was not acceptable.

Madgeek built a custom procurement platform that encoded Tejas's actual approval rules — not a simplified version of them. The system handled conditional routing based on all four variables simultaneously, gave approvers a single interface to review and act on requests, and maintained a complete timestamped audit trail on every action. Requesters could see the exact status of their requisition at any point without emailing the procurement team.

The outcome was a 90% reduction in paper-based approvals. The procurement team's time shifted from chasing status updates and filing paper to processing actual approvals. Audit preparation time dropped sharply because every decision was already documented in the system. This was not a pilot — it went into production across the organisation.

This was one of four systems Madgeek delivered for Tejas Networks over a multi-year engineering partnership. The procurement platform was the first. It established the trust that made the rest of the engagement possible.

What does a custom purchase requisition system include?

A custom purchase requisition system built for a mid-to-large enterprise includes six functional modules. Each module is built to the organisation's actual rules, not a configurable approximation of them.

• Requisition form engine — configurable forms per category that collect exactly the fields needed for each purchase type, with conditional field display based on what the requester selects
• Approval workflow engine — rule-based routing that resolves the correct approver chain before the request is submitted, based on all relevant variables (amount, category, department, vendor, project code)
• Budget validation — real-time budget check against the relevant cost centre or project budget at submission, not at approval, so over-budget requests are flagged before the chain begins
• Vendor master — vendor records with classification, payment terms, compliance status, and document storage, with vendor onboarding workflow built in
• PO generation — automatic purchase order creation from an approved requisition, formatted to the organisation's PO template, with line items, delivery terms, and payment terms populated from the requisition and vendor master
• Audit and reporting — complete action log with user, timestamp, and decision for every event; procurement dashboards showing spend by category, department, and vendor; export to accounting or ERP systems

Integrations are determined by what already exists in the organisation. ERP integration is the most common — the PR system writes committed costs and approved POs back to the ERP rather than requiring manual re-entry. Finance systems integration handles budget consumption in real time. HRMS integration keeps the approver hierarchy current when org structures change.

How long does it take to build a custom purchase requisition system?

A purpose-built purchase requisition system for an enterprise with complex approval logic takes 16–24 weeks from specification to production deployment. The timeline depends primarily on integration complexity, not on the procurement logic itself.

The work breaks into four phases:

1. Process mapping and specification (3–4 weeks) — documenting every approval rule, exception, and integration requirement before a line of code is written. This phase is where most failed procurement projects fail: insufficient specification means rework later.
2. Core system build (8–12 weeks) — requisition engine, approval workflow, budget validation, vendor master, and PO generation. This is delivered in two-week sprints with review checkpoints, not as a waterfall release.
3. Integration and data migration (3–6 weeks) — connecting to ERP, finance, and HRMS systems; migrating vendor master data; validating the integration in a staging environment before production.
4. User acceptance testing and go-live (2–4 weeks) — procurement team tests real approval scenarios; edge cases and exception handling are verified; phased rollout by department or business unit.

A simpler system — fewer approval tiers, no ERP integration, under 100 users — can go live in 10–14 weeks. Complexity in the approval rule engine adds time at Phase 1, not Phase 2. Integration with a legacy ERP that has poor API documentation adds time at Phase 3.

Common questions about purchase requisition systems

What is the difference between a purchase requisition and a purchase order?

A purchase requisition is an internal document — a request from an employee or department to procurement asking for permission to buy something. A purchase order is an external document — a formal commitment sent to a vendor authorising a specific transaction at an agreed price. The PR comes first, is approved internally, and only then generates a PO. A company that skips the PR step and goes directly to POs has no internal approval gate: anyone with access to the PO system can commit company funds.

Can a purchase requisition system connect to our existing ERP?

Yes, with the right integration approach. Modern ERPs — SAP, Oracle, Microsoft Dynamics — expose APIs that a custom PR system can write to directly. Approved requisitions push committed cost entries; approved POs push against open purchase orders in the ERP. Legacy ERPs with no API require either a middleware layer or a scheduled data exchange. The integration architecture is scoped during Phase 1 of the build, before any code is written.

How does a purchase requisition system handle approval delegation?

Approval delegation is a standard requirement and a common gap in SaaS tools. When an approver is on leave, the system needs to route their pending approvals to a designated delegate automatically — not require the procurement team to manually reassign each request. A custom system enforces delegation rules directly: approvers can set delegation periods with start and end dates, the system re-routes pending items to the delegate, and returns routing to the primary approver when the delegation ends. The audit trail records who actually approved each item, including delegations.

What does a purchase requisition system cost to build?

A custom purchase requisition system with the six modules described above, built for an organisation with 200–1,000 users and one ERP integration, costs $60,000–$120,000 to design and build. The range is determined by approval logic complexity and integration requirements. Ongoing support and feature development after go-live typically runs $2,000–$5,000 per month depending on the volume of changes. Compared to enterprise SaaS licensing at $40–$80 per user per month for 500 users — $240,000–$480,000 per year — the break-even on a custom build is 3–6 months of avoided licensing fees.

Is a purchase requisition system the same as a procurement system?

A purchase requisition system is the front end of a procurement system — the part employees interact with to initiate and track purchase requests. A full procurement system extends further: it includes vendor management, contract management, three-way matching (PO to delivery receipt to invoice), and spend analytics. Organisations building custom often start with the PR module because it delivers the highest immediate ROI — approval bottlenecks and budget leakage are solved within weeks of go-live. The contract and invoice matching modules come later once the approval workflow is stable.

If your organisation has outgrown its current procurement workflow and is evaluating whether a custom purchase requisition system makes sense, Madgeek's enterprise software work covers exactly this type of build — complex approval logic, ERP integration, and audit-ready architecture. See Madgeek's enterprise software development service for how this type of engagement is structured.