PHARMA DISTRIBUTION · PAN-EUROPEAN PROCUREMENT · PILOT COMPLETED · BATCH DELIVERED
One batch of 1,130 contracts, every page read.Delivered in the shape Ivalua imports.Every unknown named, not filled.
Europe’s largest pharmaceutical wholesaler, family-owned, moving medicines across thirty countries through ninety-six operating entities. Each entity has its own language, its own contract formats, and its own national supplier base.
Inside a programme of 22,000 contracts across thirty countries, in formats and languages that never agreed with each other, Talonic structures each batch once, delivers it in the import shape PHOENIX agreed for Ivalua, and ships every cell it could not determine as a documented blank with the reason attached.
holds=7 is not an error state.
HOW TO READ THE NUMBERS ON THIS PAGE
The customer’s whole pan-European estate. These numbers run in prose.
One delivered batch, measured from the delivered files. These numbers run inside framed instruments.
The two never share a sentence.
PHOENIX Pharmahandel
Pharma · Germany
- Industry
- Pharma distribution
- Function
- Procurement
- Solution
- Multilingual contracts, ERP-ready
PILOT COMPLETED · BATCH DELIVERED AND RECEIVED, ERP IMPORT-READY
1,130
contracts delivered, one row each, Ivalua import-ready
Note: A multilingual contract estate across thirty countries, in formats that never agreed, that purchasing could not query. One batch read once, text and image alike, and delivered as one row per contract in the shape Ivalua imports. The programme runs to 22,000 contracts.
THE PLATFORM RUN
The same five stages run on every corpus. These are this one’s numbers.
1,130
DOCUMENTS, ONE BATCH
8,641 pages. Every page read, none sampled.
59
FIELDS AT V15
Capture, extract, resolve and synthesize, explicit at every field.
96
OPERATING-ENTITY CODES
Entity first, then supplier candidates scoped to its country. Multi-part contracts assembled into one record.
70
BLANKS, EACH CLASSIFIED
Delivered in the shape Ivalua imports, with every undeterminable cell left blank and explained.
ONCE
CAPTURED, THEN PROJECTED
Ivalua is the first system that reads this data. It will not be the last, and nothing is read again.
Four of the five print a measured number: two at programme scope, two at batch scope, and the chip above each figure says which. The fifth prints a word: Ivalua is the first downstream system delivered, and the read is not repeated for the ones that follow.
Note: The fifth stage prints ONCE on purpose: it is the claim every page in this family exists to receipt.
READ ONCE · QUERY FOREVER
01 / every unknown named
Every unknown named, not filled.
A programme of 22,000 contracts across thirty countries and ninety-six operating entities. One batch of 1,130 contracts, every page read. Seventy blanks, every one of them classified.
Inside a programme of 22,000 contracts across thirty countries, in formats and languages that never agreed with each other, Talonic structures each batch once, delivers it in the import shape PHOENIX agreed for Ivalua, and ships every cell it could not determine as a documented blank with the reason attached.
A contract estate across thirty countries and eight languages, in formats that never agreed with each other. The contracts were valid and the information was in them. What purchasing intelligence, supplier decisions and planning could not do was use it without someone reopening the documents.
A twelve-document pilot on the hardest documents first, then one batch of 1,130 documents and 8,641 pages, every page read and none sampled. Roughly 12,430 decision cells verified at one hundred percent, eleven adversarial rounds, and seventy blanks each with its reason written beside it. The programme runs to 22,000 contracts. That is the estate, not the delivery.
Ivalua is the first system that reads it. The same rows serve purchasing and contract intelligence, supplier and contract-risk analysis, reporting and planning, and later automation, without anyone reopening the original documents.
1,130
DOCUMENTS, ONE BATCH
8,641 pages. Every page read, none sampled.
Two tables, two scopes. The programme is the customer’s whole pan-European estate, and those numbers run in prose. The batch is one delivery, August 2026, measured from the delivered files, and those numbers run inside framed instruments. The two never share a sentence.
Pilot completed. One contract batch delivered and received in ERP import-ready format. The wider programme is stated as scope.
Every figure on this page is what we measured about our own work, at the scope we measured it, with the denominator printed beside it. Engagement-level accuracy is shared under NDA.
Everything below this band is the receipt for it: the estate, the pilot on the hardest documents, one supplier question per contract, the encoding, what was built, and the ledger underneath.
02 / the estate
PROGRAMMENinety-six operating entities.Eight languages.One supplier question per contract.
PHOENIX does not have a procurement contract corpus. It has hundreds: one per operating entity, each in its own language, its own formats, its own 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 thirty countries.
When PHOENIX moved to Ivalua as the unified procurement platform, every contract had to be re-read, re-structured and re-classified before it could be loaded. The programme corpus runs to 22,000 vendor contracts, and one contractual relationship is rarely one document: a master agreement, two amendments, an annexe and a data processing addendum all have to arrive as one record.
Corpora also arrive incomplete, and nobody knows until someone asks the right question. Three source folders surfaced here only after a question about a country whose contracts were not showing up in the data. That is why the first stage of every delivery is a census: count the documents, hash both sides of the copy, and close the reconciliation identity before any model reads a page.
Coverage is proven against pages, never against ledgers.
Eight in the delivered corpus, with more in scope as the programme extends.
Thirty in scope. In scope is a statement about the programme, not a delivery status per country.
Two in a single batch: Cyrillic, and Latin with carons and strokes. Byte-true everywhere, including inside company names.
Ivalua is the first system that reads this data. It will not be the last.
96 operating entities distributed across 30 countries in scope, columns ordered by entity count, largest first. 2 of those countries carry no entity in this list.
MOVE ACROSS THE MATRIX TO NAME AN ENTITY
96 OPERATING ENTITIES · 30 COUNTRIES IN SCOPE
2 COLUMNS CARRY NO ENTITY · IN SCOPE IS A PROGRAMME STATEMENT, NOT A DELIVERY STATUS PER COUNTRY
supplier_code · one question per contractStand-in imagery, not a photograph of the customer.Stand-in imagery. Not a PHOENIX facility.03 / the pilot
BATCH · AUG 2026The first twelve documents we readwere the worst ones we could find.
Twelve deliberately hard documents, 654 pages, read at one hundred percent and re-read: the longest, the most script-dense in each language, an amendment, a converted office file, documents with handwritten signature blocks. A pilot only proves the properties you verified the sample actually has.
Every downstream check is checking the record, not the pages. So a reader that never saw the pages still produces a perfectly formed record, every check downstream of it still passes, and the errors land exactly where a customer notices them: dates, amounts, and company names. This is how a reader goes blind.
When a reader asks for a batch of page images, the images can come back empty. No picture, no error message. The request succeeds. The reader receives nothing and does not know it.
assert images_received == images_requestedThe measured reliable ceiling was three images per read. Batches of ten and five failed silently. An unasserted read is a defect regardless of batch size. The page-image read and the assertion that now guards it are defined in the Spec and run in the platform.
- Decimal truncation in two of two filled amount cells.
- A twenty-five percent error rate on handwritten dates at first read, zero percent after magnified second reads.
- A duplicate-writer collision with no lock.
- Company names printed in mixed scripts, which would have broken supplier matching silently.
The pilot is roughly a day of the schedule and it is not optional. It paid for itself several times over on day one.
04 / one supplier question
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 sits in a country with no Phoenix subsidiary.
Most extraction systems treat operating entity and supplier code as independent fields. Both get extracted in parallel, both get resolved in parallel, and on a corpus like this one the result is 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 graph governs every conditional field in the schema: payment terms scoped to the supplier’s region, document types to the contract family, language defaults to the entity’s jurisdiction.
Each guard exists because it caught a real wrong match. That is the only reason any of them are in the layer.
- COUNTRYNo candidate outside the entity’s country is eligible. An empty entity means an empty code, never a guess.
- DISTINCTIVE TOKENWithout it, an earlier gate passed rows matched on “Solutions”, “Software”, “Group” and a country name.
- LEGAL FORMThe only same-named candidate in a country subset can still be a differently constituted legal person.
- NAME SANITYIdentifier matching once shipped one company’s code under a completely different company’s name. Twenty-nine candidates were rejected and handed over in their own column rather than shipped or discarded.
On the PHOENIX corpus this mechanism cleared cross-country false matches, re-resolved supplier codes inside country-scoped subsets, and routed the ambiguous rows to a structured triage queue rather than letting them ship as silent errors.
It generalizes to every multi-jurisdiction extraction problem.
05 / the encoding
Two scripts.No single code page holds both.
Cyrillic and Central-European Latin in one batch, byte-true everywhere.
Two documents printed a company name in Latin letters with a single Cyrillic letter hidden inside, one of them six times over. To a person they look identical. To a matcher they are different strings, and supplier matching would have missed them silently. Mixed-script tokens are preserved and flagged, never corrected.
No character anywhere in the package has been dropped, substituted, transliterated or approximated to fit a code page.
The specification asked for a single-byte Western code page. The corpus mixes Cyrillic with Central-European Latin, so that is not achievable, and the correct response is to measure it rather than approximate it.
What shipped: one authoritative complete copy in a universal encoding, plus one folder per single-byte code page carrying only the subset that survives it exactly, with identical file names and identical headers in every folder, so any one of them can be read without change.
Note: The rows fitting two code pages but not the third numbered zero, so the assignment needed no tie-break and produced the only possible disjoint split. The clean per-script separation is a consequence of the measurement, not a rule anyone imposed.
All 1,070 subset rows were read back from disk, decoded in their own code page and compared cell by cell against the master, not sampled, with zero mismatches. The Cyrillic file matched byte for byte at 2,071,174 bytes.
06 / what we built
PROGRAMMESix things that make this corpus tractable.
59 fields, V15 in production. Capture, extract, resolve and synthesize tiers, explicit at every field.
A delivery in the customer’s current import shape, byte-level reproducible from source. UTF-8 authoritative, versioned post-processing, no manual edits.
Eight languages in the delivered corpus. Ninety-six operating-entity codes resolved across thirty countries.
A relationship spanning a master agreement, amendments, annexes and a data processing addendum is assembled into one delivered record, with the amendments overriding the master by signing date.
A routing companion, an unresolved-supplier companion carrying the candidate column, a triage queue, and a one-page validation report. The data steward never opens a delivery file blind.
A versioned delivery contract. Every number in every delivery document is re-derived from the final bytes at the moment of writing, never carried forward and never hand-typed.
A single relationship in this corpus routinely spans separate PDFs with separate filenames, sometimes uploaded years apart. The master agreement establishes the relationship, the amendments override its fields by signing date, and the annexe and the addendum inherit governance from the master. The row that ships represents the contract as it stands today.
07 / next
Want to see this on your corpus?
Send a representative sample of your contracts. We run them through Talonic and send back your extracted data within five business days: field-level coverage, confidence, and provenance. You judge the output field by field instead of taking a percentage on trust.
SIX CASE STUDIES: INDUSTRIAL ENERGY · GETEC / PHARMA WHOLESALE · PHOENIX PHARMAHANDEL / LOGISTICS · BRIDGEWAY / AUTOMOTIVE · MARUTI SUZUKI / RESEARCH · WZB / INDUSTRIAL HYDRAULICS · BOSCH REXROTH
THE LEDGER
Everything above this line, with its receipt.
The argument ends here. What follows is the working: every population, every date, every denominator, and the places our own account needs checking. Nothing below is needed to understand the case. All of it is needed to check it.
L1 / every blank named
BATCH · AUG 2026Seventy blanks.Every one of them classified.
The most instructive hold in the run was not a data defect. The data files were clean and the release was held anyway, twice, on the paperwork: disputed cells were not disclosed in the package, and the arithmetic in the delivery notes did not close. Two of the late holds were taken on the delivery documents, not on the data. The rule that came out of it is now the governance line of this page: every number in every delivery document is re-derived from the final bytes at the moment of writing, never carried forward and never hand-typed.
A plausible wrong value is poison in procurement master data. A documented blank is not.
70
DOCUMENTED BLANKS
Not seventy failures. Seventy cells whose cause is written down beside them.
Buying entity resolved on 1,060 of 1,130 documents: 1,042 from the document’s own printed entity, where 102 printed spellings collapsed onto 5 nodes by an explicit family rule applied longest-match-first, and 18 from the entity-coded folder, used only where the document itself is silent. That leaves 70 empty, each classified by cause: 51 print no buying entity at all, 14 print an entity with no node in the master listing, and 5 name between two and five.
Fourteen of those blanks are not our gap and not the customer’s error: their printed entity has no node in the master listing at all. If the master gains those nodes, fourteen rows resolve and their suppliers become matchable. That turns a gap into a request, and a request is something a data steward can act on this week.
An email-domain resolution tier was defined and measured at 96.2% over 132 rows on one domain and 100% over 5 on another, and it filled zero additional rows, because every row carrying those domains already named its entity. A measured and unused tier is a finding, not wasted work.
An empty cell without a reason is not compliant with this rule: the reason is the deliverable. Placeholder strings are banned outright, with no “N/A”, no “none”, no “unknown” and no dash. An empty signature date is a real signal, because it means the instrument is not executed, and filling it destroys the signal.
Two supplier rows could not be confirmed, so they shipped empty, with the best candidate disclosed in its own column beside them. The receiving side adopted both candidates verbatim.
Candidates you bury in notes die there. Candidates you ship as data get used.
L2 / the receipts
BATCH · AUG 2026Four rings. Eleven attempts to break it.Seven of them held.
A builder self-check, then a continuous checker running alongside extraction, then an adjudicated page-true pass, then adversarial cold eyes on the final delivered bytes, then a human release gate. Maker, checker and adversary are always different parties, and a checker never reuses the builder’s code. These verification behaviours are defined in the engagement’s Spec and run in the platform.
If the check shares a code path with the thing it checks, it is decorative.
Eleven decision fields across 1,130 documents, roughly 12,430 decision cells verified at one hundred percent with no sampling, against 57,630 cells swept structurally. Long documents were read twice, by two independent readers.
Every one of those defects was found and fixed before the package left the building. They are what the verification caught, not what the delivery carried.
Sixty-seven of the 305 distinct flags, twenty-two percent, did not survive: thirty-seven disposed by a written ruling, thirty refuted at the page itself.
A page-true pass that produces no refutations is not a clean corpus; it is an uncalibrated verifier.
Round 1 found the package “mechanically excellent, substantively leaky”: every structural attack failed, and what got through was content and governance.
A check battery only catches shapes someone designed a check for.
The first build rebuilt a pool of 8,189 references, found zero collisions, and said so while noting the pool was about 184 smaller than expected and the gap could not be closed. An adversarial review extended the pool to 11,746 and two real collisions appeared. The disclosure is what found them.
Note: 253 flags went to page verification in 28 batches. 223 confirmed plus 30 refuted is the 253.
7
HOLDS IN ELEVEN ADVERSARIAL ROUNDS
Four passes ended ship-ready. A hold is the system working, and it is the number this page is proudest of.
Two of the late holds were taken on the delivery documents, not on the data.
A machine does not release. A person does, and the disputes ship in the box with the data.
Two tables. Two scopes.
Note: The customer’s estate. Carried from the built page and the published customer section.
Note: Measured from the delivered bytes, with the denominator printed beside it.
L3 / withheld · WHAT STAYS WITH THE CUSTOMER
Engagement-level accuracy is shared under NDA. What is published is what we measured about our own work, at the scope we measured it, with the denominator printed beside it.
Revenue and headcount stay with the customer. The shape of the business carries the sentence instead.
The thirty countries in scope are a statement about the programme. The country the documented batch came from stays with the customer.
Supplier-master specifics stay with the customer: per-country pool sizes, real supplier names, real prices and real contract references. The resolver trace and the assembly figure are illustrative and say so.
Findings letters, complaint counts and defect counts from prior deliveries stay with the customer.
What the receiving side renamed, flattened, dropped or transcoded after handover stays with the receiving side. The rule ships.
No person is named on either side, and a quotation appears here once it is signed.
Three further blocks are drafted and laid out: the residual-risk statement, the coverage-maturity comparison against the earliest accepted delivery, and the specification escalation. Each renders below when its switch is on.
SUMMARY
What this case shows
FOUR CLAIMS
Four things this engagement demonstrates, each with the figure that backs it. Every one of them is checkable against the ledger above.
- 01
One read serves thirty countries
A multilingual estate in formats that never agreed, text and image alike, read in one batch and delivered as one row per contract in the shape Ivalua imports.
1,130 contracts · 8,641 pages - 02
Hard documents first, none sampled
The pilot started on the hardest documents, and every page of the batch was read rather than sampled. Roughly 12,430 decision cells were verified across eleven adversarial rounds.
12,430 cells · 11 rounds - 03
A blank with a reason beats a guess
Seventy blanks were delivered with the reason written beside each one. Every blank is printed on this page with its reason, rather than hidden in the data.
70 blanks · each with a reason - 04
Delivered is a shape, not a promise
The batch was received in ERP import-ready form, in the shape PHOENIX agreed for Ivalua. The wider programme runs to 22,000 contracts: estate, not delivery.
ERP import-ready · 22,000-contract programme