Graph
A unified supplier master: the same supplier, only once
Unified supplier master data brings under a single identity the legal entities, accounts and codes behind which one supplier appears several times. Graph, the knowledge graph layer, builds it through entity resolution, as it reads your documents: grouping legal entities, spotting duplicates, aligning item references, converting units of measure.
The problem
The same supplier, counted five times
A supplier group signs with your head office, invoices from two subsidiaries, collects under a third legal entity and gets created a fourth time during a data migration. On your screens those are five separate accounts. Each carries part of the spend, none carries the real figure. The same item, meanwhile, exists under the supplier reference, under your internal code and under one inherited from an acquired subsidiary.
The consequence is twofold. Your consolidated exposure is wrong: you negotiate believing you weigh a fifth of what you actually weigh. And price comparison becomes impossible: the same product shows two prices that cannot be compared, because one is per litre and the other per twenty-five-litre drum.
Every invoice creates knowledge. Without a graph, it goes straight back into a PDF.
Entity resolution, step by step
This is the second step in building the graph, and the decisive one for suppliers. It does not run once during a migration: it runs on every incoming document, and corrects the master data as it goes.
- Group the legal entities
- The entities that invoice are attached to their supplier group: legal identifiers, addresses, bank details, contract headers and subsidiary mentions are cross-checked. The accounts stay separate for the ledger; the exposure reads consolidated.
- Spot the duplicates
- Two records created six months apart for the same account, one comma apart in the name, are matched and flagged. The graph merges nothing silently: it proposes the match together with the documents that ground it.
- Align the item references
- The supplier reference, your internal code and the description printed on the invoice are all linked to the same item. The same product ordered under three references from the same supplier stops looking like three unrelated purchases.
- Convert the units
- Litre and drum, metre and roll, hour and day, pallet and unit: units of measure are converted to a common base, with the factor used and the document line that justifies it. Without that, no unit price is comparable.
- Attach to your classification and to a bridge taxonomy
- Every item joins your internal purchasing category, then a bridge taxonomy: UNSPSC (the United Nations Standard Products and Services Code, more than 50,000 categories, available in some fifteen languages and maintained by GS1 US) or eCl@ss, which exists as an OWL (Web Ontology Language) ontology. The bridge is what lets you compare a category across subsidiaries whose own classifications have drifted apart.
Every match leaves a trace: the document, the page and the line behind it, the agent that wrote it, the date. Unified supplier master data is only worth having if each of its merges can be opened and inspected.
“Our data is far too messy for this”
This is the most common objection, and it describes exactly the expected starting point. Entity resolution is not a step that assumes clean data: it is the step that exists because the data is not clean.
- Multiple legal entities, duplicates and diverging item codes are the normal input to the process, not a prerequisite to sort out before starting.
- The master data is not built in a separate project: it fills up while the agents handle your invoices, contracts and purchase orders.
- Nothing is rewritten in your systems. The match lives in the graph; your ERP (enterprise resource planning system) keeps its accounts exactly as they are.
- Whatever stays ambiguous stays ambiguous, and is flagged as such. An uncertain match is proposed, never applied in silence.
Memory stops being individual. A renegotiation starts from what was actually invoiced, not from the theoretical rate.
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
How does the graph group the legal entities of one supplier?
By cross-checking legal identifiers, addresses, bank details and contract headers read in your own documents. The accounts stay separate in the ledger; the graph adds a “belongs to the group” relationship on top, which makes consolidated exposure readable without touching your entries.
What happens to our internal classification?
It is kept and remains the reference your teams use. The graph additionally links it to a bridge taxonomy, UNSPSC or eCl@ss, so a category can be compared across subsidiaries whose classifications have diverged. You keep your vocabulary; the bridge only maps the scopes onto each other.
Does the data need to be perfectly clean?
No. The Capture agent is designed for heterogeneous documents and incomplete reference data; structuring is part of the deliverable.
How do I check a Zylio conclusion?
Every discrepancy opens onto its evidence: the contract clause and the invoice line, highlighted side by side, with the calculation shown.
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.
- The procurement ontology: the blueprint before the houseWhat the graph is allowed to hold, declared before the first ingestion.
- Purchase price historyTimestamped facts: every price stays tied to its period and to its evidence.
- Procurement data traceabilityEvery match opens onto the document, the page and the line behind it.
- 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