Graph
The knowledge graph of your procurement: every price linked to its contract and its evidence
A procurement knowledge graph is the connected map of your spend: suppliers, contracts, items, prices, purchase orders and invoices, joined by explicit relationships. Graph builds it from the documents the agents already read, and ties every relationship to the document, the page and the line it came from.
Graph
Every invoice creates knowledge. Without a graph, it goes straight back into a PDF.
Every invoice processed creates knowledge: a price, a discount, a reference, a lead time, a contract that applies. That knowledge lives for the duration of one check, then goes straight back into the source PDF and into the memory of whoever handled it. Six months later, the renegotiation starts from the theoretical rate again, and the question “what did we actually pay, where, under which contract” is reopened by hand.
Book a demo
Customer casesNothing is lost. Everything can be checked, everything can be proven.
- The contract clause and the invoice line, highlighted side by side.
- Every extracted value stays linked to the exact place in the document where it was read.
- The same case produces the same decision, today as in six months: the rules are applied deterministically.
- No discrepancy is set aside in silence. Anything that matches no rule is raised, with its reason.
- The agent records what it did, in the order it did it: who, what, how much, when.
Procurement intelligence · Graph
All your purchasing knowledge, connected and queryable.
Turns the documents the agents have already read (contracts, amendments, schedules of unit prices, rate cards, purchase orders, goods receipts, invoices, credit notes) into a typed graph built on a procurement ontology that ships with the product: entities joined by explicit relationships, each one tied to the document, the page and the line it came from. An edge without a source never enters the graph.
What Graph detects
- The same supplier under several legal entities
- The same item under several references depending on the supplier
- Units of measure that do not compare
- An internal classification that has drifted
- Contracts nobody can tell still cover the spend in progress
- Credit notes promised and never applied to the invoice they came from
Memory stops being individual. A renegotiation starts from what was actually invoiced, not from the theoretical rate.
Ontology and graph: the distinction the market blurs
The ontology is the blueprint. The graph is the house.
The ontology declares what exists in the world of procurement and how those things may relate. The graph holds the facts: that supplier delivers that reference, at that price, under that contract. Using the two words interchangeably is mistaking an architect’s drawing for a building people live in.
The consequence is commercial, and it is where everything is decided: the procurement ontology ships with the product, it is not yours to build. Graph projects almost always fail on that step: the domain has to be modelled before anything can be ingested, and that work calls for skills few organisations hold in house. Zylio arrives with a procurement ontology already built, proven on the documents its agents read every day. You have no modelling to do.
The entities you get
The typed relationships
How the graph is built
The approaches documented on the market build the graph from the ERP or from reference data that is already clean. Zylio builds it from the contractual and transactional documents themselves, because its agents already read them.
Ingestion by the agents, not by an import
Capture brings the lines, Compliance brings the negotiated terms, Matching brings the links between purchase order, goods receipt and invoice. The graph waits for no data migration project: it fills up as the processing runs.
Entity resolution
Legal entities grouped under a single supplier group, duplicates detected, item references aligned across suppliers, units converted, everything tied to your internal classification and to a bridge taxonomy: UNSPSC, which holds more than 50,000 categories in some fifteen languages and is maintained by GS1 US, or eCl@ss, available as an OWL (Web Ontology Language) ontology.
Admission control
Whatever does not conform to the ontology is rejected, not written. The graph accumulates only relationships someone deliberately modelled: that is the difference between a graph and a store of approximate triples.
Provenance on every edge
Every relationship carries its source: document, page, line, date, the agent that wrote it, the confidence level. An edge without a source never enters the graph.
Continuous update
Every new document updates the graph. Facts are not overwritten but time-stamped, which makes price history queryable over time, period by period.
Provenance, side by side
An edge of the graph opens onto the document it came from. On the left, the relationship as the graph holds it; on the right, the line as it was read, on the page where it sits, with the agent and the date of reading.
The relationship in the graph
- Supplier ACME Industrie
- supplies → ref. 4471-B
- €12.40 · under contract CAD-2024-17
Its source
- Invoice F-2026-0912
- page 3 · line 18
- read by Capture on 12/03
Our graph holds nothing we cannot trace back to the document line it came from.
That is what makes a relationship enforceable against a supplier: it is checked on the document, not on a claim. And it is what constrains the AI rather than feeding it: whatever is not in the ontology does not enter, whatever has no source does not exist.
The questions it answers
These are questions that cross several objects at once. The tables of an ERP cannot join them; the graph answers them because the relationships there are explicit and dated.
- What price do we pay for the same reference by entity, by site and by period, and which contract governs each of those prices?
- Which suppliers in fact belong to the same group, and what is our consolidated exposure?
- Which indexation clauses fall due within 90 days, and on what volumes already committed?
- What share of the spend in a category is genuinely covered by a contract, and by which one?
- Which promised credit notes have never been applied, and against which original invoice?
- Is the same item being ordered under three different references from the same supplier?
- If we lose this supplier, which references have no alternative on record?
What we say and others do not
The subject is crowded with interchangeable promises. Here, line by line, is what we write instead.
The usual pitch
The graph gives visibility over the supply chain
What Zylio says
The graph makes spend queryable, and every edge is enforceable against a supplier
The usual pitch
Build your ontology, then your graph
What Zylio says
The procurement ontology ships with the product; you have no modelling to do
The usual pitch
We connect your systems
What Zylio says
We start from your documents, including those held in no system at all
The usual pitch
The graph feeds the AI
What Zylio says
The graph constrains the AI: whatever is not in the ontology does not enter, whatever has no source does not exist
The usual pitch
Institutional memory
What Zylio says
Dated and sourced memory: the March price, the clause of amendment 3, line 18 of invoice 4471
The Graph cluster
Six pages to go into detail: the blueprint, the supplier master data, price history, the evidence, the comparison with a data warehouse, and the single reference base that links contracts, orders and invoices.
- The procurement ontology: the blueprint before the houseWhat a procurement ontology declares, and why it ships with the product rather than being built.
- Unified supplier master data: the same supplier, onceEntity resolution, groups, duplicates: how five legal entities become one supplier again.
- Purchase price history: what price, when, under which contractFacts time-stamped rather than overwritten: the price paid can be read back period by period.
- Procurement data traceability: an edge without a source never enters the graphDocument, page, line, date, agent, confidence level: what every relationship carries.
- Graph or data warehouse: what each one can answerWhat a warehouse models in advance, what a graph answers without having planned for it.
- Link contracts, orders and invoicesI link my contracts, my orders and my invoices in a single reference base
Frequently asked questions
What is a procurement knowledge graph?
It is the connected representation of your spend: entities (suppliers, contracts, items, purchase orders, invoices) joined by explicit, typed relationships, each one tied to the document it came from. Where a table sets columns side by side, a graph links objects; that is what makes it possible to answer a question that crosses several of them.
What is the difference between an ontology and a graph?
The ontology is the blueprint, the graph is the house. The ontology declares what exists in the world of procurement and how those things may relate; the graph holds the facts: this supplier delivers this reference, at this price, under this contract. At Zylio, the procurement ontology ships with the product.
Is a data migration project required?
No. The ontology ships with the product and ingestion is done by the agents that already process your documents: the graph fills up while the checks run. It is not a two-year project to complete beforehand, it is an effect of everyday processing.
How does the graph handle duplicate suppliers?
That is what the entity resolution step is for: multiple legal entities are grouped under a single supplier group, duplicates are detected, item references are aligned across suppliers and units are converted. Heterogeneous data is the normal input to the graph, not a prerequisite to fix beforehand.
How do you check a piece of information in the graph?
Every edge opens onto its source: the document, the page, the line, the date and the agent that wrote it. Information without a source never entered the graph, so there is nothing to take on trust.
Is my data used to train models?
No, never. It is not shared between clients and stays hosted in France.
Measurable impact in every environment
More than 5 million procurement documents analysed
Between 1 and 7% of margin recovered
on the scope analysed
From 15 to 45% of time given back to teams, per FTE
depending on the scope and on data maturity
Zylio fits into your existing ecosystem.
The ERP runs the process. Zylio handles the exception and recovers the value that escapes it: invoices without a purchase order, line-by-line price discrepancies, duplicates and overbilling, off-contract spend.
IA
Your data under high security.
- Certifications
- SOC 2 Type II · ISO 27001
- Hosting
- Hosted in France
- Encryption
- End-to-end AES-256 encryption
- Access
- Enterprise SSO · multi-factor authentication · Zero Trust approach
The five Zylio agents
- CaptureGather and consolidate all your procurement data.
- CompareCompare supplier offers, objectively.
- ComplianceEvery invoice checked against your agreements.
- MatchingPurchase order, goods receipt and invoice matching, automated.
- ExceptionInvoices without a purchase order, multi-order invoices, duplicates: handled.
Procurement intelligence: the two intelligence layers
See what this looks like on your own data
Twenty minutes, on a spend category of your choosing. We show you what the agents detect, with the evidence behind it.
- No commitment, on your own data
- Result in 3 weeks
- 20 minutes, no sales pitch
- Your data stays hosted in France
- No change of tool or process