Twenty-two thousand vendor contracts. Ninety-six operating entities. Eight languages. One schema. Ivalua-ready.
PHOENIX Pharmahandel — Europe’s largest pharmaceutical wholesaler, €32B+ revenue, family-owned, operating across thirty countries — asked Talonic to structure their entire pan-European procurement contract corpus for migration into Ivalua, with the same registry projecting onward to every downstream system that follows.
REQUEST A SCHEMA AUDIT →96 operating entities · 30+ countries · ↓ scroll to inspect
Most procurement migrations stall at the documents.
PHOENIX Pharmahandel does not have a single procurement contract corpus. It has hundreds of corpora — one per operating entity, each in a different language, each in a different format, each touching a different national supplier base. Tamro in Finland and Sweden. PHOENIX OCP in France. Phoenix Healthcare Distribution, L. Rowland, Nupharm, and NuCare in the United Kingdom. Phoenix Farmacija in Croatia. Norsk Medisinaldepot in Norway. Ninety-six operating-entity codes in total, across more than thirty countries.
When PHOENIX moved to Ivalua as the unified procurement platform, every contract in this corpus had to be re-read, re-structured, and re-classified before it could be loaded. The corpus brought to Talonic spanned 22,000 vendor contracts in eight languages, with multi-part contractual relationships — a master agreement with two amendments, an annexe, and a DPA — that had to resolve as a single contractual record.
The customer needed the corpus structured against a 59-field schema, validated against Ivalua’s import rules, and reproducibly delivered. Without manual review at scale.
The patterns repeat across European distribution.
Multi-jurisdiction supplier bases. Localized contract language. Multi-part contract structures. Ivalua, SAP Ariba, Coupa, or downstream proprietary systems all need the same registry. Once a pharma schema is locked, it ports across distributors.
SEE THE PHARMA VERTICAL →FOR PROCUREMENT TRANSFORMATIONThe migration most enterprises postpone.
Pre-existing contracts that have to be carried into a new procurement platform. The mechanism described below is built for that exact migration — regardless of vertical.
SEE THE PROCUREMENT USE CASE →FOR TECHNICAL BUYERSDependency-graph resolution. Country-scoped reference lookups. The Cases primitive for multi-part documents.
The architectural specifics are below. Skip ahead.
SKIP TO THE MECHANISM →Six things that make this corpus tractable.
A 59-field extraction schema in production. Capture → Extract → Resolve → Synthesize tiers, explicit at every field. Contract identity, parties, financial terms, dates, lifecycle, governance, operating-entity assignment. V15.
A 47-column Ivalua-conformant CSV delivery, byte-level reproducible from source. UTF-8, CRLF, semicolon-delimited, double-quoted text, DD-MM-YYYY dates, fr-FR decimal formatting. Versioned post-processing. No manual edits.
Eight languages handled in one corpus: English, German, French, Finnish, Swedish, Croatian, Norwegian, Portuguese, Slovenian. With Italian, Dutch, Romanian following in scope. Ninety-six operating-entity codes resolved across thirty countries.
A single contractual relationship that spans a master agreement, amendments, annexes, and a DPA resolves as one contractual record in the registry. Inheritance rules between parts are explicit and versioned.
Every delivery ships with a triage queue, an unresolved-supplier list, a parent-reference retention file, and a one-page validation report. The data steward never opens a delivery file blind.
A versioned delivery contract between Talonic and PHOENIX. Every delivery validates against it before shipping. Changes require sign-off from PHOENIX’s nominated owner. Reproducible from source on demand.
59-FIELD SCHEMA EXPLORER
Supplier resolution is not a field extraction. It’s a dependency graph.
In a multi-jurisdiction supplier base, the same supplier name resolves to different supplier codes depending on which operating entity is the contractual counterparty. A supplier called “Phoenix Healthcare Distribution” maps to one code when the entity is UK01, a different code when the entity is IE00, and nothing at all when the entity is in a country without a Phoenix subsidiary.
Most extraction systems treat operating entity and supplier code as independent fields. Both get extracted in parallel. Both get resolved in parallel. The result, on a corpus like PHOENIX’s: cross-country false matches at scale.
Talonic resolves them as a dependency graph. Operating entity first. Then supplier candidates scoped to that entity’s country.
The same resolution graph applies to every conditional field across the schema — payment terms scoped to the supplier’s region, document types scoped to the contract family, language defaults scoped to the operating entity’s jurisdiction.
On the PHOENIX corpus, this mechanism cleared one hundred and ninety-six cross-country false matches, re-resolved thirty-eight supplier codes within country-scoped subsets, and routed one hundred and fifty-eight ambiguous rows to a structured triage queue — rather than letting them ship as silent errors. The mechanism generalizes to every multi-jurisdiction extraction problem.
Capture once. Project to every system that follows.
Ivalua is one downstream system. PHOENIX’s procurement transformation will not stop there. SAP Ariba, Coupa, internal data warehouses, vendor risk scoring, contract intelligence agents — each one will eventually need to read the same source documents through a different schema.
A parser-based migration solves this once and re-extracts every time the downstream changes. The Registry approach captures the documents once, structures them once, and projects them into every future schema without re-reading the source corpus.
PHOENIX CORPUS
22,000 CONTRACTS
59 FIELDS
THE REGISTRY
For PHOENIX, that means the same 22,000 documents that load into Ivalua this year power every subsequent procurement system change at zero re-extraction cost.
The pharma schema, once locked, also ports to the rest of European pharmaceutical distribution — the field structure, the multi-part contract logic, and the country-scoped resolver carry across to every distributor with a comparable supplier base.
Five documents. One contractual record.
A vendor relationship in a procurement system is rarely one document. It’s a master agreement plus its amendments, plus an annexe defining the SLA, plus a data processing addendum.
In the PHOENIX corpus, the average relationship spanned three or more documents — separate PDFs, separate filenames, sometimes uploaded years apart.
Talonic resolves them as a single contractual record. The master agreement establishes the relationship. The amendments override its fields by signing date. The annexe and DPA inherit governance attributes from the master. The Ivalua row that ships represents the contract as it stands today.
Inheritance rules are explicit, versioned, and inspectable per record.
Thirty countries. Ninety-six entities. Eight languages, growing to twelve.
No accuracy figures are published here. Engagement-level accuracy is shared under NDA.