Watch a single purchase request move through the full procure-to-pay cycle, from intake to invoice.
A procurement software demo should show you four things end to end: how a purchase request gets submitted, how it gets approved, how the purchase order is generated, and how the supplier invoice comes back against it. What matters most is the joins between them, because that is where requests stall and fields get retyped.
This walkthrough follows a single request flow through Zapro the whole way. An employee raises it from the catalog, the procurement team prices what the employee couldn’t, four approvers clear it in sequence, the purchase order generates itself, the PO flips into a goods receipt, and the invoice arrives — either submitted by the supplier through their portal, or emailed in as a PDF and parsed automatically into matched or match-failure status. Nothing is skipped and nothing is edited around.
Below you’ll also find the 12-point checklist we use to evaluate any procurement platform demo, including demos of software that isn’t ours. Take it into every vendor call you sit through.
Key takeaways
- A useful demo follows one request end to end; module tours hide the handoffs where implementations fail.
- The purchase request form decides how much work every downstream stage creates.
- Approvals stall because nobody knows who is holding the request, not because anyone is deliberating.
- If a purchase order has to be typed manually, the demo has already failed.
- Three-way match is the real test — and a match that fails is the part vendors skip.
- Six of the seven procurement process groups run inside your organisation; the seventh runs on the supplier side.
- Time your last ten purchase requests before any vendor call — that baseline is the problem you’re buying software to solve.
Watch the full procurement software demo video
What’s covered in this demo
Every chapter below corresponds to a moment in the video. The order is the order the cycle runs in.
| Time | Step | What you’ll see |
|---|---|---|
| 33:47 | Dashboard | Four KPIs, purchase by category, purchase by supplier, task and activity boards |
| 34:12 | Raising a purchase request | Pre-populated general information, purchase reason, catalog and non-catalog items |
| 34:57 | Workflow, history and comments | The approval workflow populated automatically, a record of who created and submitted the request, and an internal comment thread |
| 35:16 | Filling in the request detail | Supplier and site, shipping and payment terms, contracts, billing address, budget check, split bill, line- and header-level attachments |
| 36:01 | Submitting the request | PR #429 submitted, then appearing in the dashboard and the notification queue |
| 36:40 | The procurement team’s pass | Price, unit of measure and supplier set on the requester’s behalf |
| 38:07 | The approval chain | Buyer, HOD, finance and admin; approvers added and removed mid-flight |
| 38:31 | Purchase order | Generated on final approval, showing received and invoiced quantities |
| 38:47 | Goods receipt | The PO flipped into receipt 152 |
| 39:29 | Invoice | Supplier portal submission, a PO flipped into an invoice, and emailed PDFs parsed to matched or match-failure |
| 40:22 | Sourcing, expenses and contracts | RFQ awarding by best total or best supplier with savings shown; expense submission; contract module |
| 42:37 | Approval flow configuration | Parallel and serial conditions |
Earlier chapters cover the AI maturity curve, where AI fits across the seven procurement process groups, and the benefits and risks of each. Audience Q&A follows the walkthrough.
Five things this procurement software demo shows that most don’t
1. The PR form decides everything downstream
Whatever the requester gets right at this stage, nobody has to chase or re-enter later. Whatever they leave blank becomes a phone call, a bounced request, or a purchase order corrected after it has reached a supplier.
Zapro pre-fills what the system already knows and asks the employee only for what they alone can supply. The request then forks: a catalog item carries its own price, supplier and unit of measure and passes straight through, while a non-catalog request leaves the commercial detail for procurement to complete. That fork decides how much work each request creates.
Three quieter decisions matter almost as much — budget is checked before submission rather than after approval, cost is split across departments as the request is raised rather than reconstructed by finance later, and attachments sit at line or header level so a document stays with the item it supports.
2. An approval chain you can see is an approval chain you can chase
Approvals rarely stall because someone is deliberating. They stall because nobody knows who is holding the request.
Here the chain is visible from the moment the request is submitted — buyer, head of department, finance, admin, with the current stage marked and the rest waiting — so finding it is a matter of looking rather than asking. Approvers can be added from a list or removed while the request is still live, for the cases a standing chain didn’t anticipate.
And the chain is configurable in shape as well as membership: reviewers whose decisions don’t depend on each other can sit in parallel rather than in sequence, which is the difference between a cycle timed by its slowest approver and one timed by all of them combined.
3. If the PO has to be typed, the demo has already failed
Someone has to supply the supplier and the price, and the requester often can’t. That work happens inside the request, or on a purchase order later.
Zapro puts it in first. Procurement is the opening stage of the approval chain, so where a requester couldn’t supply the supplier, price or unit of measure — the cleaning service in the walkthrough — it fills those in before the request moves on. Catalog items pass through untouched.
When the last approver signs off, the purchase order generates from the approved request rather than being typed again, showing received and invoiced quantities as the cycle runs.
4. Three-way match is the real test, and it’s the part vendors skip
Matching is not a new application of AI. Invoice extraction, reconciliation and multi-way matching were already automated well before generative tools arrived, and they demand more rigour than most AI use cases because they deal with financial data rather than suggestions.
What shapes AP workload is how invoices arrive, and there are three routes. The supplier submits through the supplier portal, which is the usual one. You raise the invoice yourself from the purchase order, for suppliers who depend on you to do it. Or the supplier emails a PDF, which is parsed and lands as matched or match-failure without anyone opening it. The register then shows whether each invoice is PO-backed, contract-backed or direct, which tells you what it has to be reconciled against before you open it.
The walkthrough stops at capture. The step after it is the one worth demanding from any vendor, including us: an invoice where the quantity received doesn’t match the quantity invoiced.
Want to see the match that fails?
It isn’t in the recording, and most vendors won’t show it. Bring your messiest supplier invoice to a live session and we’ll run it through the exception queue on screen — tolerance rules, who gets notified, and what happens next.
Book a free demo 30 minutes · No credit card · Bring your own invoice
5. The supplier side is half the workflow
Six of the seven procurement process groups run inside your organisation. The seventh runs outside it. Suppliers respond to sourcing events, sign contracts, submit catalogs, acknowledge purchase orders and raise invoices, and none of the first six completes without them.
That is why the walkthrough treats the supplier portal as the normal route for an invoice rather than as an integration option, with you raising the invoice only where a supplier depends on you to do it.
It is also where the data quality problem sits. B2B suppliers are generally weak at descriptions, imagery, classification and tagging, which is why catalog content usually needs work before anyone can search it usefully — and why catalog enrichment is one of the clearer uses for generative tools. When you evaluate a platform, look closely at what the supplier is asked to do, and at how much of it your team ends up doing instead.
Why most procurement software demos tell you nothing
Most demos are organised around what a product can do: modules, dashboards and integrations, each shown on its own. That is a reasonable way to present software and a weak way to evaluate it, because capabilities shown separately never reveal how they connect.
What you rarely see is a single purchase request travelling from someone’s desk to a paid invoice. The parts easiest to demonstrate are the ones that look the same for every buyer. The parts that decide whether an implementation succeeds — the form your team fills in, the routing your finance lead maintains, the exception queue your AP clerk works in — are specific to your process, harder to show, and usually left out.
So the more useful request is: show me one purchase request, from the moment someone needs something to the moment the supplier is paid, without cutting away.
Procurement problems are rarely capability problems. Almost every platform can raise a purchase order. What separates them is what happens at the handoffs — requester to procurement, procurement to approver, approver to PO, PO to receipt, receipt to invoice. Each handoff is a place where a request stalls, a field gets retyped, or an invoice arrives with no PO behind it.
A demo that never crosses a handoff hasn’t told you much about the software you are about to buy.
What to look for in a procurement software demo: a 12-point checklist
Each item below is a handoff, or the evidence that one holds. They run in the order the cycle does, from a request being raised to the data landing in your ERP. Use the list in every vendor demo you sit through, including ours — and if a vendor can’t demonstrate an item live, that’s the answer.
| # | Ask the vendor to show you | What a good answer looks like |
|---|---|---|
| 1 | A request submitted by a non-finance employee | The form is completable without training or a phone call |
| 2 | A budget check before submission | The requester learns there’s no budget now, not after four approvals |
| 3 | An approval routed on something other than amount | Conditions on vendor status, data access, category, entity |
| 4 | The approver’s notification | Reaches them where they already work, not only inside the platform |
| 5 | A PO generated with zero manual typing | Every field populated from the original request |
| 6 | The PO sent to a supplier | Sent from inside the platform, with attachments and terms intact |
| 7 | An invoice arriving and being read | Extraction shown live on a real emailed PDF, not a clean sample |
| 8 | A three-way match completing | PO, goods receipt, and invoice reconciled on screen |
| 9 | A match that fails | The exception queue, the tolerance rules, and who gets notified |
| 10 | The ERP write-back | Direction, frequency, and what happens when it errors |
| 11 | An audit trail on a changed record | Who changed what, when, and the prior value |
| 12 | The same workflow on a phone | Approvals happen on mobile or they don’t happen at all |
Item 9 is the one vendors resist. Insist on it.
Take the checklist into every vendor call
A one-page PDF you can score each vendor against, out of 12. Print it, share it with finance and IT, and use it on us as well as on everyone else.
What to do before you book any procurement demo
- Pull your last ten purchase requests and time them. Note the date each was raised and the date the PO was issued. The gap between those numbers is the problem you’re buying software to solve, and you need the baseline before a vendor quotes you an improvement against it.
- Find the one request type where the amount doesn’t reflect the risk. Every organisation has one — a low-value engagement carrying data access, compliance exposure, or a long contract tail. Write down the routing rule that would catch it, then ask every vendor to build that rule live.
- Decide who does the pricing. In the walkthrough above, procurement fills in the supplier and cost the requester couldn’t. Some teams want that; others want requesters to complete everything. Whichever you run, make the vendor demo it, because it changes the shape of the form and the routing.
- Take the checklist into the call. Score each vendor out of 12. The scores will separate them further than the pricing does.
See it against your own workflow
You’ve seen the walkthrough. The next useful step is running your own scenario — your approval matrix, your ERP, your worst invoice — against the platform. That takes 30 minutes with someone from our team.
Bring these three things:
- Your requisition-to-PO baseline from the last ten requests
- The routing rule that should catch your riskiest low-value request
- Your messiest supplier invoice — a clean sample proves nothing
Procurement software demo FAQs
Can I see a demo for procurement software without talking to sales?
Yes. The video on this page is ungated, with no form in front of it. If you’d like to see the same workflow run with your own approval matrix, your own ERP and your own invoice exceptions, book a free procurement software demo and the session will be built around them.
How long does a procurement software demo take?
The recording on this page runs 46 minutes and covers the full cycle from request to invoice. A live demo tailored to your process typically runs 30 to 45 minutes, and a technical deep-dive covering ERP integration and data migration usually needs a separate hour with your IT team present.
What should I ask during a procurement platform demo?
Work through the 12-point checklist above. The two questions that separate vendors fastest are: show me a three-way match that fails, and show me an approval routed on something other than the amount. Most demos avoid both.
Does the requester have to know the supplier and the price?
No. The walkthrough shows both paths. Where the requester picks a catalog item, the request passes through untouched. Where they ask for something like a cleaning service without knowing the supplier or the cost, the procurement team sets the price, unit of measure, and supplier on their behalf before the request moves to approvers.
How do invoices reach Zapro?
Three ways. The supplier submits through the supplier portal, which is the usual route. You flip an approved PO into an invoice where the supplier depends on you to raise it. Or the supplier emails a PDF, which is parsed automatically and lands in matched or match-failure status.
Can approvers be changed after a request is submitted?
Yes. The walkthrough shows approvers added from a list and removed from an in-flight chain. Routing conditions themselves can run in parallel where reviewers don’t block each other, or in sequence where they do.
Does Zapro integrate with our ERP?
Zapro supports data and supplier integration with common finance and ERP systems. Bring your ERP version and any customisations to the live session — that’s where integration conversations usually turn out to be simpler or more complicated than expected.
Can I see a demo of specific modules only?
Yes. Zapro covers end-to-end procurement, vendor management, strategic sourcing, contract management, spend analytics, AP automation, inventory management, and ERP integrations. Tell us which modules are in scope when you book and the session will be built around those.
Don’t miss our weekly updates
We’ll email you 1-3 times per week—and never share your information.
Healthcare
Financial Services
Technology
Venture Capitalist