Supplier invoice review on a synthetic finance dataset
Which supplier invoices should a finance team examine, why, and how does it know the review case was really opened?
From incoming data to an observed result
- 1
Admission of incoming data
A first demonstrator reads a local API page by page: 18 incremental changes are applied once and 6 redelivered events are ignored. A second, larger extract of 1,175,515 journal lines and 175,165 supplier invoices for two companies enters with a dataset passport: declared source, scope, row populations, the SHA-256 digest of every file and a detached Ed25519 signature. A modified passport fails verification.
- 2
Preparation with explained rejections
A raw, prepared and business-layer pipeline runs on a distributed data-processing engine in local mode. 65 defective documents were injected into the source; all 65 were quarantined with their reason: unbalanced document, invalid currency or impossible date. No unbalanced document reaches the business layer, and the trial balance holds for each company and year.
- 3
Detection that is measured, not assumed
Five rule families run in SQL over the prepared data and are scored against injected anomalies that the detector cannot read. Four of them find every injected case with at most 2 false alerts. A naive near-duplicate rule also finds every case, with 7.4% precision. That is why the lab never automates a financial action.
- 4
A bounded outbound request
The only action the lab can request is opening a review case in a simulated target. Each request must fit a mandate (one allowed action, a ceiling of five cases, an expiry), carry an approval bound to its exact content and refer to an unchanged invoice. Six kinds of refusal are exercised; none leaves an effect.
- 5
The observed result comes back as evidence
When the acknowledgement is lost, the state is recorded as outcome unknown and resolved by reading the target back. A repeated request does not create a second case. Every attempt leaves a receipt.
What the run produced
Every figure below comes from the run of 18 September 2026. Synthetic data from a seeded generator: no client system and no client data.
1,175,515
journal lines prepared by a distributed data-processing engine, run in local mode
65 of 65
defects injected into the source and quarantined, each with its reason
0
unbalanced documents reaching the business layer
7.4%
precision of a naive near-duplicate rule: every injected case found, among 373 false alerts
13
receipts: 5 review cases for a ceiling of 5, and 6 refusals that left no effect
66
automated tests across the two demonstrators, all passing
What this case does not show
- A connection to a client's ERP system, or to any production system.
- A distributed cluster: the processing engine ran in local mode, on two processors.
- A language model or a vector search: document retrieval in the lab is lexical.
- The FxChain core: the admission and dispatch boundaries are illustrated, not executed by the protocol.
- Results on client data: these figures describe one synthetic test set.
The hypothesis behind it
Data platforms already provide access control, audit and lineage. The hypothesis tested here is narrower: reducing the work needed to establish, across several systems and owners, which data was used, which processing version ran, which action was authorized and which result was actually observed.
A similar problem on your side?
Describe it in a few lines. The answer states what can be measured, on which data, and what cannot.