Graph
The procurement ontology: the blueprint before the house
A procurement ontology declares what exists in your purchasing (suppliers, contracts, items, prices, invoices) and how those things may connect. The ontology is the blueprint, the graph is the house. At Zylio the blueprint ships with Graph: there is no modelling to do before the first document is ingested.
The problem
The step where graph projects stall
A graph fills up with nothing until someone has said what it should hold. Before the first line is ingested, you have to decide that a contract “governs” a rate schedule, that an invoice line is “charged to” a purchase order, that one supplier “belongs to the group” of another. That modelling calls for a procurement expert and a knowledge engineer at the same time. Few organisations have both to hand, and none has them free for six months.
Skip that step and two outcomes follow. The project stops at the modelling workshop, for want of a ruling on vocabulary. Or ingestion starts anyway, and you end up with a store of loose relationships where “supplier” means a legal entity here, a group there, a subledger account in your ERP (enterprise resource planning system) somewhere else. Both cost a year and answer no question.
Every invoice creates knowledge. Without a graph, it goes straight back into a PDF.
The ontology is the blueprint. The graph is the house.
The literature on the subject uses the two words as synonyms; they name two different things. The ontology declares what may exist and how those things are allowed to connect. The graph holds the facts: that supplier delivers that reference, at that price, under that contract, in that entity. The blueprint is not the house, but nothing gets built without it.
- The declared entities
- Supplier group, supplier, legal entity, site, contract, amendment, clause, rate schedule or schedule of unit prices, item, supplier reference, purchasing category, purchase order, order line, goods receipt, invoice, invoice line, credit note, payment, indexation index, currency, unit of measure.
- The typed relationships
- Supplies, referenced as, governed by, priced by, indexed on, converted into, classified under, invoiced for, received by, charged to, replaces, belongs to the group. Every relationship has a declared meaning, a declared source and a declared target: it links only what it is allowed to link.
A relationship missing from that blueprint means nothing to the graph: it is rejected, not written. That is the real difference between a graph and a pile of triples gathered as they came, where nothing guarantees that two edges with the same name are talking about the same thing.
An ontology delivered, not a project
- It is already built. You open no modelling workshop: the blueprint arrives with Graph, entities and relationships included.
- It has been tested on the documents the agents read every day: contracts, amendments, schedules of unit prices, rate cards, purchase orders, goods receipts, invoices, credit notes. It was written against real paperwork, not against a theoretical schema.
- It speaks to the market standards. UNSPSC (the United Nations Standard Products and Services Code, more than 50,000 categories, available in some fifteen languages and maintained by GS1 US) and eCl@ss act as a bridge taxonomy for purchasing categories; eCl@ss also exists as an OWL (Web Ontology Language) ontology, the standard language for describing ontologies.
- It takes in your vocabulary. Your purchasing families, your cost dimensions and your legal entities attach to the delivered blueprint: they do not replace it and they do not force it to be redrawn.
The practical consequence: the graph fills up while the checks are running. Ingestion goes through the agents that already handle your paperwork: Capture brings the lines, Compliance the negotiated terms, Matching the links between order, receipt and invoice. There is no data migration project first, because there is no blueprint left to draw.
Memory stops being individual. A renegotiation starts from what was actually invoiced, not from the theoretical rate. It investigates, you decide.
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.
Memory stops being individual. A renegotiation starts from what was actually invoiced, not from the theoretical rate.
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
Nothing 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.
Frequently asked questions
What is the difference between an ontology and a knowledge graph?
The ontology declares what may exist and how things connect: it is the blueprint. The graph holds the facts themselves: that supplier, that price, that contract, on that date. Without an ontology, a graph piles up relationships nobody defined; with one, whatever does not conform is rejected rather than written.
Do we have to build our procurement ontology before we start?
No. The procurement ontology ships with Graph, entities and typed relationships included, and it has been tested on the documents the agents already read. Your specifics (purchasing families, cost dimensions, legal entities) attach to it. The blueprint does not have to be drawn, and the graph does not wait for it.
Does Zylio replace my ERP?
No. Your ERP runs the process and remains the source of truth. Zylio handles the exception, on top of it, and feeds the results back. No additional development inside your system.
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.
Your data under high security.
Zylio meets the most demanding standards, and nothing is committed without your approval.
- Certifications
- Hosting
- Encryption
- Access
Read next
- Graph: the knowledge graph of your procurementThe parent page: how the graph is built, queried and verified.
- Unified supplier master dataThe blueprint applied to suppliers: the same supplier, only once.
- Purchase price historyTimestamped facts: every price stays tied to its period and to its evidence.
- Procurement data traceabilityEvery relationship carries its document, its page, its line and its date.
- Graph or data warehouseWhat each one can answer, and why both belong side by side.
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