Graph

Graph or data warehouse: what each one can answer

Graph or data warehouse: the question is not which tool to pick, but which shape of question each one can handle. A data warehouse answers very well what it was modelled for in advance. The graph answers what crosses several objects without having been planned for: the usual shape of a buyer’s questions.

Book a demo Request a diagnostic

The distinction

Two ways of preparing an answer

A data warehouse is built around a model decided up front: fact tables, analysis dimensions, aggregates. That model is a bet on the questions to come. When the question asked matches the bet, the answer is immediate and reliable, which is exactly why warehouses get installed, and no reason to do without one.

The bet holds up less well when the question was not foreseen. Adding a dimension, linking a contract clause to an invoice line, surfacing the notion of a supplier group where the model only knows accounts: each of those requests becomes a development, ranked in a BI (business intelligence) backlog. Six weeks later, the negotiation has already happened.

Every invoice creates knowledge. Without a graph, it goes straight back into a PDF.

What each one handles naturally

Neither superiority nor replacement: two data structures with different shapes, and therefore different easy questions. The useful comparison is about the shape of the question, not about the technology.

The warehouse is at ease with

Stable, repeated aggregates: the month’s spend, by entity, by cost family.
Series tracked without changing the definition from one quarter to the next.
Very large volumes across a limited set of dimensions known in advance.
Regulatory and budget reporting, whose format does not move.

The graph is at ease with

Multi-hop questions: from the contract to the clause, from the clause to the invoice line, from the line to the entity that paid it.
Links that were not in the original model: membership of a supplier group, alternative item reference, credit note promised and never applied.
Dated facts queried over time, with no period planned in advance.
Questions asked only once, for which nobody will open a development project.

The two coexist without conflict. The graph does not replace the warehouse: it takes the share of questions the model did not anticipate, and it can feed the warehouse with datasets that are already reconciled: suppliers grouped, units converted, categories attached.

The demonstration: questions that cross

Here is the real shape of a buyer’s questions. None of them is answered by a fact table: each starts from one object and crosses three more.

Consolidated exposure: Which suppliers actually belong to the same group, and what is our consolidated exposure? The group link does not exist among ledger accounts: it is inferred from the documents, then traversed.
Credit notes never applied: Which promised credit notes were never applied, and against which original invoice? The promise sits in a contractual exchange, the offset in an accounting line: both ends have to be joined.
Duplicate references: Is the same item ordered under three different references from the same supplier? The question assumes the references have been aligned onto one item, which no aggregate does.
Supplier dependency: If we lose this supplier, which references have no alternative on record? That is a question of structure, not of volume: it is answered by walking relationships, not by summing lines.

Where the data comes from, and why it changes everything

Most graph approaches plug into the systems already in place: they take what the warehouse already holds, limits included. Zylio starts from the documents themselves (contracts, amendments, rate schedules, purchase orders, goods receipts, invoices, credit notes), including those that sit in no system at all. This is possible because the agents already read that paperwork to check your spend.

A warehouse fed by your systems cannot know a clause that was never keyed in. The graph knows it, because it read it in the amendment, and it keeps the page and the line. That is also what makes the answer verifiable rather than declarative.

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.

Discover Graph What the AI does, and never does: the Zylio AI mandate

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

Do we have to replace our data warehouse with a graph?

No. A warehouse answers well the questions it was modelled for, and those questions remain useful. The graph handles the ones that cross several objects without having been planned for, and it can supply the warehouse with already reconciled datasets. Both coexist, each on its own shape of question.

Which questions does a data warehouse handle poorly?

The ones chaining several relationships the model never planned for: going from an invoice line up to the clause that governs it, then to the group the supplier belongs to, then to the volumes committed elsewhere. Each extra hop means a development in a warehouse, while it is already written in the graph.

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.

Which tools does Zylio connect to?

To the ERPs and management tools already in place, including SAP, Sage, Oracle and Pennylane, as well as to existing document repositories, mailboxes and feeds.

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.

All integrations

Your data under high security.

Zylio meets the most demanding standards, and nothing is committed without your approval.

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

Security and compliance

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