Agentic Procurement Analytics & Approvals

The challenge

The platform already held what its customers needed — supplier records, purchase orders, contracts, line items, cost and profit centres, GL codes, exceptions and a full audit history. Getting an answer out of it was the problem. A finance lead who wanted to know which suppliers had drifted above contracted rates last quarter, or which approvals had been sitting untouched too long, had to ask an analyst, wait, then ask a follow-up. Each customer ran on its own tenant with its own data views, so a query written for one organisation could not be reused for another. Three constraints shaped everything that followed:

• Nothing may be invented. A finance assistant that produces a plausible number is worse than one that produces nothing.
• Tenants must stay sealed. One organisation’s data can never surface in another’s session, and users can only act within their own authorisation scope.
• Actions must be reversible in principle and auditable in practice. Approving or rejecting a payable document is a real financial event.

What we built

We built an agentic assistant that sits inside the platform as a chat panel and behaves like an analyst who already knows the schema. Users ask in ordinary language; the assistant works out what kind of request it is, writes and validates SQL against that tenant’s governed views, runs it read-only, and returns a formatted table with links back into the platform.

• Answers, then actions. From the same conversation a user can approve or reject items, chart a trend, forecast next quarter’s costs, generate an Excel export, email it to a colleague, or set up a recurring delivery by saying “every Monday at 8am”.
• Grounded in the customer’s own paperwork. Uploaded contracts, policies and supplier agreements are extracted, chunked, embedded and indexed per tenant, so answers cite the customer’s documents rather than general knowledge.

How it works

Every message enters an orchestration graph of specialised nodes. The data-query path runs like this.

• Intent routingClassifies into data query, analytics, forecasting, action, reporting, scheduling or document retrieval
• Schema groundingSelects the relevant fields from the tenant’s governed views
• Query generationSQL checked for syntax and safety before it is allowed to execute
• Self-correctionDatabase errors are fed back and the query regenerated, not failed to the user
• Grounded summaryWritten only from the returned rows, with the executed query alongside

A governed set of views per tenant gives the assistant a controlled surface: it reads what the customer’s own permissions allow and nothing else. Returning the executed query alongside the answer means any user or auditor can see exactly what was run.

Acting from the conversation

• Confirmation gate. When a request would change state, the assistant resolves the target records, checks eligibility, then stops and asks for confirmation in plain language before anything is written. Every action is logged with user, timestamp, before-and-after field values and outcome.
• Analytics and forecasting. For trend questions it selects an appropriate chart type, generates the visualisation specification, and writes findings from the actual dataset. Forecasting projects costs and volumes forward from the tenant’s own history.
• Scheduled delivery. Recurring reports are described conversationally, stored as timezone-aware schedules, and delivered by email as Excel attachments without further prompting.
• Streaming transparency. Progress streams over a WebSocket, naming each step, so users watch the reasoning rather than a spinner.

Results

Engineering practice

• Measured, not estimated. Per-response instrumentation for latency and token usage, so the cost and speed of every conversation is measurable.
• Automated review. Daily and weekly analysis of usage logs and user feedback, feeding directly into prompt and workflow improvements.
• Isolation enforced server-side. Tenant boundaries are enforced outside the model, and authentication tokens are never exposed to it.

Outcome

The assistant runs in production across multiple enterprise tenants. Questions that previously required an analyst and a wait are answered in the conversation where they were asked, and approvals, exports and report scheduling happen without leaving it. The audit trail is queryable in plain language, so “who approved this and when” is a question the system answers rather than a database investigation.

Instrumentation added during the build turned model cost from an unknown into a monitored line item.

Why it matters

Most enterprise software problems are not data problems. The data is already there. The gap is between the person with the question and the schema that holds the answer, and that gap is usually staffed by an analyst. Closing it needs more than a language model bolted onto a database: the model constrained to governed views, its SQL validated before execution, its answers grounded in returned rows, its actions gated behind human confirmation, and every step logged. Those constraints are what make a finance team willing to trust the output.

Technology

• LangGraph
• LangChain
• Azure OpenAI
• Azure AI Search
• Microsoft SQL Server
• Azure Document Intelligence
• Azure Blob & Table Storage
• Python 3
• FastAPI
• WebSockets
• APScheduler
• SendGrid
• Plotly
• Docker