From weeks of manual spend analysis to tender-ready savings opportunities.

Platform and data

1. 01

   Build the foundation first

   We set up the platform from the first commit: a monorepo with shared libraries, infrastructure as code on Azure with separate development, test and production environments, and CI checks on every pull request. Each AI service runs as its own queue-based worker, so heavy jobs scale and retry without blocking the product.

2. 02

   Connect the data where it lives

   We built integrations to the customer's spend analytics platform and to the sourcing platform where tenders run. ERP and Excel exports are imported for customers without a direct connection.

3. 03

   Solve the data problems that block everything else

   Supplier matching recognizes the same supplier across datasets with no shared IDs. Payment terms normalization turns free-text terms such as "60 days net, 2% discount within 3 days" into structured net payment days, in several languages.

Supplier intelligence

1. 04

   Give every supplier a profile

   Spend data says how much was bought, not what a supplier can do. The enrichment pipeline combines transaction descriptions, contract documents and external company research into a structured profile, from a universal core down to three levels of category. Each field is backed by a data source and carries two scores. Confidence says how certain the value is. Data sufficiency says how much evidence the data holds for it. Where the evidence is too thin, the profile says so instead of guessing.

Opportunity engine

1. 05

   Find the opportunities a procurement analyst would find

   The opportunity scanner follows the steps a category manager takes. It measures fragmentation per category, identifies tail spend, clusters suppliers and proposes consolidation, standardization and spot-buy opportunities with estimated savings. We reviewed the workflow with procurement practitioners, so the logic matches how the work is done.

2. 06

   Balance breadth and caution

   An opportunity engine can fail in two directions. Too eager, and it consolidates away a small supplier the business depends on. Too cautious, and it finds nothing worth a tender. The evals measured both. They tracked how well opportunities covered each industry domain, and checked that small but specialized key vendors were protected.

3. 07

   Map contract constraints instead of hiding them

   Each supplier is checked against existing contracts. Contracts that run beyond the end of the fiscal year are flagged, so the category manager sees the constraint and its timing. About 20% of suppliers had contracts running beyond the fiscal year and could not yet be included in opportunities. The rest are not blocked by a long contract. They are still mapped, so they can be planned for when the contract allows.

RFx generation

1. 08

   Draft the tender

   For each opportunity, three agents produce the RFx package: a project brief, a supplier questionnaire and an item grid with pricing fields. Prompts are specific to the category. Guard rails stop the documents from revealing the buyer's internal strategy. Outputs are validated against a schema and unit prices are enforced.

2. 09

   Push it into the sourcing platform

   The RFx package is created as a sourcing project in the customer's sourcing platform, with questionnaire, grids, schedule, team and suppliers attached. A category manager opens a ready tender instead of a blank one.

Evals and release

1. 10

   Give every stage a contract and test it

   We wrote down what each stage must deliver and built an evaluation for each one. Procurement experts labeled what correct looks like. Deterministic checks cover what code can verify. LLM judges cover the rest, calibrated against the experts and against known judge biases first.

2. 11

   Test the whole chain on real customer scenarios

   Each customer has reference scenarios from anonymized real data, reviewed by experts and then frozen. When an end-to-end result drops, we rerun the chain with one stage replaced by its correct output. That shows which stage caused the drop.

3. 12

   Release on evidence

   Contract flagging, RFx leakage and data reconciliation block any release on failure. Supplier merge precision blocks a release when it falls below its minimum. Everything else is gated against the normal run-to-run variation of each test pack. A new customer passes the same gate on its own data before it sees results.

4. 13

   Choose models for accuracy

   Retrieving the right data, extracting it and labeling suppliers correctly decides the quality of everything downstream. We ran the pipeline mainly on Claude models and did not trade accuracy for a cheaper model.

Production

1. 14

   Learn from production

   Adopted and dismissed opportunities, edits to generated RFx documents and corrections to supplier profiles are all signals. Drift is checked on each new data load. Reviewed cases flow back into the test sets.

Platform and data

• Platform foundation

  Monorepo, shared libraries, queue-based workers, infrastructure as code on Azure across three environments, CI checks.

• Spend data integrations

  Automated import from the customer's spend analytics platform, plus ERP and Excel importers.

• Data services

  Supplier matching across datasets, multilingual payment terms normalization, LLM-based OCR and retrieval over contracts.

Supplier intelligence

• Supplier enrichment and ranking

  Category-aware profiles from transactions, documents and external research, with capability tags, source-backed fields and confidence scores. Suppliers ranked per capability.

Opportunity engine

• Opportunity scanner and validation

  Fragmentation analysis, tail spend detection, supplier clustering, savings opportunities, contract term flagging and protection of key vendors.

RFx generation

• RFx generator and platform integration

  Project brief, questionnaire and item grid agents with category-specific prompts, created as sourcing projects in the customer's platform.

Evals and release

• Evaluation and release gate

  Expert-labeled test sets, deterministic checks and calibrated judges for all ten stages, reference scenarios per customer and release-critical metrics.

Production

• Production monitoring and cost control

  Opportunity adoption and dismissal reasons, RFx edit tracking, drift checks, and per-service AI budgets with tracing.

Platform and data

• Messy data stops blocking analysis

  Supplier matching and payment terms normalization are both above 90% accuracy. Days of spreadsheet work become a pipeline run.

Supplier intelligence

• Supplier profiles are backed by data

  Every field in a profile links to the data source it came from, so users can check any value. Where an industry has less data or less public information about its companies, confidence is lower, and the user can see it.

Opportunity engine

• Millions in estimated savings potential

  The scanner runs the analysis a category manager would do, across all categories at once. For its enterprise customers it identified millions in estimated savings potential, with single opportunities of €500K to €20 million. These are estimates, not realized savings.

• About 60% of opportunities adopted

  Across more than 50 proposed opportunities, end customers adopted about six in ten. Adopted means a tender was started. The evals made the breadth of opportunities across domains measurable, protected specialized key vendors and kept the engine balanced between too eager and too cautious. We believe this balance is a main reason for the adoption rate.

• Contract constraints are visible, not surprising

  About 20% of suppliers were tied up by contracts beyond the fiscal year. They are mapped and timed for when the contract allows, instead of being lost or proposed too early.

RFx generation

• RFx preparation takes about 80% less effort

  Category managers review and send a tender instead of writing one. The figure compares creating a tender manually with generating it by AI and adjusting it by hand afterwards, across the same more than 50 opportunities. It is a reduction in preparation effort. Most of the remaining effort goes into adjusting capability grids. Leakage tests make sure no target price or internal note reaches a supplier.

Evals and release

• Stable results across customers

  Each data load is reconciled and checked for drift. Changes are tested on all customers before release. New customers pass the same gate on their own data before they see results.