How We Automated Requisition-to-PO for a UK Construction Firm

Most construction firms run procurement on spreadsheets, email threads, and phone calls. Requisitions get lost. Purchase orders get duplicated. Deliveries arrive on site with no record of what was ordered or by whom. We built a system that fixes this.

This article walks through the procurement automation we designed and deployed for a UK construction firm. It covers the full pipeline: material requests, requisitions, purchase orders, delivery tracking, and invoice reconciliation. Every step is auditable, role-gated, and connected to the accounting system through signed webhooks.

The Problem: Procurement Without a System

Construction procurement is messy by default. A site manager needs materials. They send an email or fill in a shared spreadsheet. Someone in the office turns that into a purchase order, maybe in Word, maybe in another spreadsheet. The supplier gets a phone call or a PDF over email. When the delivery shows up on site, nobody checks it against the original order. Invoices come in weeks later with no way to trace them back.

The firm we worked with had exactly this problem. Multiple active sites, a growing team, and zero structured visibility into what was being ordered, by whom, at what cost, or whether it had actually arrived. They weren't a small operation. They were scaling, and the cracks were showing.

What We Built: The REQ-to-PO Pipeline

We built a structured procurement pipeline inside a React application backed by Supabase (PostgreSQL), with workflow automation handled by n8n and accounting sync handled through Xero.

The pipeline has four stages:

1. Material Request. A site manager logs what they need. This is internal tracking only: open, closed, or cancelled. It captures the need before any supplier is involved.
2. Requisition (REQ). The request becomes a formal requisition with a unique reference number. Line items are added with quantities and supplier quotes. The requisition moves through a defined approval flow: draft, ready for quote, quoted, ready for PO, approved, or rejected.
3. Purchase Order (PO). Once a requisition is approved, a purchase order is created directly from it. Line items, quantities, and supplier details carry over. The PO gets its own approval chain and can be sent to the supplier.
4. Delivery and Invoice. When goods arrive on site, the system tracks partial and complete deliveries against the PO. Invoices are attached to the PO with automatic VAT calculation, then synced to Xero through a webhook.

Every transition is logged. Every approval records who approved it, when, and with what notes. There are no gaps in the chain.

Site-Prefixed Numbering

Construction firms operate across multiple sites. A numbering system that works for one site falls apart when you have five running at once.

We implemented site-prefixed sequential numbering. Each site has a short code. Requisitions are numbered REQ-LB001, REQ-LB002, and so on, where LB is the site prefix. When a requisition becomes a purchase order, the mapping is deterministic: REQ-LB001 becomes PO-LB001. A unique database index prevents duplicate creation.

This sounds simple. It is. But it means any team member can look at a PO number and immediately know which site it belongs to and which requisition it came from. No lookup table needed.

HMAC-Hardened Webhook Security

The system sends data to external services: n8n for workflow orchestration, Xero for accounting. These integrations run on webhooks. An unsecured webhook is a vulnerability. Anyone who discovers the URL can send fake payloads.

We built a webhook gateway as a Supabase Edge Function (Deno runtime) that signs every outbound request with HMAC-SHA256. Here is how it works:

• The gateway concatenates a Unix timestamp with the request body.
• It signs the result using a shared secret with HMAC-SHA256.
• Three headers are attached to every outbound request: X-Webhook-Signature (the signature), X-Webhook-Timestamp (the timestamp), and X-Correlation-Id (for tracing).
• The receiving system verifies the signature and rejects anything that doesn't match.

Every delivery is tracked in a webhook_deliveries table. The status moves through pending, processing, delivered, failed, or dead_letter. Failed deliveries retry with exponential backoff: immediately, then 60 seconds, 300 seconds, 900 seconds, and finally 3,600 seconds. Unknown event types go straight to dead letter. No silent failures.

Document Control That Follows ISO 9001

Construction projects generate documents. Safety plans, drawings, approval records, handover packs. Most firms store these in shared drives with no version control and no approval workflow.

We built document control into the same system. The lifecycle is structured: upload, submit for approval, approve or reject, supersede when a new version is approved, and transmit to external parties. Every approval records the actor's name, the timestamp, and any notes. Rejected documents include the reason.

External users (contractors, subcontractors, clients) see only approved or superseded documents on the sites they've been assigned to. They can't see draft documents, internal procurement data, or audit logs. This is enforced at the database level through 105 row-level security policies, not through UI-level hiding.

The document viewer was recently rebuilt as a viewer-first architecture: split-panel layout with inline file preview, approval history, revision chain, and transmittal context all visible without navigating away. All 10 implementation items were completed with zero database migrations and zero new dependencies.

What the Numbers Look Like

The system covers 45 database tables with 871 columns. There are roughly 40 PostgreSQL functions handling everything from permission checks to PO total calculations to approval workflows. The front end is a React 19 single-page application with role-based routing and guard components that enforce access boundaries.

Nine Playwright end-to-end test suites validate the core workflows. A client handover pack was delivered with the commercial proposal, the technical handbook, and the institutional readiness documentation including ISO 9001 controls mapping.

This is what a custom command suite looks like for construction procurement. Not a configured SaaS tool. Not a template. A purpose-built operational system that matches how the business actually works.