THE DISCREPANCY SESSION
One page. What it is, what it costs you, what you get, and how it ends.
RUN ONE NOW, ON A SYNTHETIC TENANT
The session below runs the same nine steps we run on your data, on one purchase order from the synthetic tenant. Every figure is DEMO sample data from the tenant file. Assign an owner, record a resolution, and end with a decision packet you can download.
Identify the conflict
Purchase order PO-4471820 is stated two ways. Two systems each hold a figure for the same object, and the figures differ. Each is true to its own record; the disagreement exists only above them.
Show the source records
System Region Value Recorded SAP S/4HANA AMER 184,200 Apr 12, 9:14 AM UTC NetSuite EMEA 179,640 Apr 12, 11:02 AM UTC Both values are kept as recorded. Neither is chosen.
Quantify it
4,560
The two records are 4,560 apart, 2.5% of the larger figure (computed: 184,200 minus 179,640). Sample units, DEMO.
Check freshness
The two records were written 108 minutes apart on the same day; the SAP record is the older. The sample carries no later read of either system. On a live tenant each source shows its last read time and its last change time here.
Show provenance
Each value is traced to the dated record that produced it: the SAP value to PO-4471820 in SAP S/4HANA (AMER) as recorded Apr 12, 9:14 AM UTC; the NetSuite value to PO-4471820 in NetSuite (EMEA) as recorded Apr 12, 11:02 AM UTC. The contract that governs the order is the contract repository, clause 4.2.
State the likely cause
- Conclusion
- The gap is most likely freight, billed once and recorded twice. INFERRED, not observed.
- Why
- The two values are 4,560 apart (OBSERVED, both records as above, 108 minutes apart). The tenant file's own note on this order gives that cause (the sample's stated cause, not a finding EOS made here).
- Sources
- SAP S/4HANA (AMER); NetSuite (EMEA); the tenant file.
- Recommended action
- Ask the owner below to confirm the duplicate freight line in the system that recorded it twice, and to correct it at the source. EOS writes to neither system.
- Expected impact
- 0 to 4,560 (MODELED): the full gap if the cause is confirmed, nothing if it is not.
- Assumptions
- The gap is a single line item. The larger figure is the one that includes the duplicate.
Assign an owner
Authority over a contested figure sits with a named person. Choose who holds it for this order.
Unassigned.
Track the resolution
Preserve the evidence
Both source values, their timestamps and the log above are kept together and pinned to the moment they were found, so the finding reconstructs later when a source record has changed. The evidence set for this session hashes to:
computing
The decision packet
The packet gathers the nine steps into one object a decision maker can read and file. It prepares a decision; it does not make one. Built here, on this device, from the state above.
A packet becomes a proof when its hash is published and anyone can check it against the record. How a decision packet becomes a proof, on the verification ledger.
THE CLAIM WE ARE TESTING
Your systems of record are each internally correct and collectively inconsistent. Nobody owns the layer above them, so the disagreement surfaces late, found by a person, usually during a close or an audit.
We think we can show you one of those disagreements in your own data, quantify it, and trace it to the record that caused it. If we cannot, that is a result too, and you owe nothing.
WHAT IT COSTS YOU
| Scoping call | 30 minutes |
| Deployment | One afternoon, your infrastructure |
| Working session | 90 minutes |
| Your people | One person who can grant read credentials. One who knows the domain |
| Cost | Nothing |
| Commitment | None. There is no contract to sign to run this |
What we do not need: a migration, a data extract, a change to any system, a project code, or a place on your roadmap.
WHAT WE CONNECT TO
Two systems that disagree. Not eight. Two is enough to prove the thesis and small enough to approve in a week.
The best pair is usually one financial source of record and one operational one, ideally where the estate grew by acquisition. If you run one ERP with clean master data, tell us now, because this session is less likely to find anything and we would rather say so than waste your afternoon.
Read-only, always. There is no write path in the connector contract. Nothing is created, updated or deleted in any system you own.
THE FIVE STEPS
1. Scope, 30 minutes. You name two systems and one domain: procurement, inventory, supplier terms, or margin. We tell you what read access is needed, field by field.
2. Access, your timeline. Read-only service accounts, scoped to the fields named in step one. Your security team approves what they can see written down.
3. Set up, one afternoon. In the hosted service (Google Cloud, one region, United States), in a workspace scoped to your organization; nothing is installed in your environment. A packaged install that runs inside your environment, disconnected, is not built yet.
4. Reconcile, overnight. The platform reads both systems, resolves them to one canonical shape, keeps every source value beside its canonical form, and finds where they disagree.
5. The session, 90 minutes. We open the largest disagreement together, trace it to the source record and the rule that produced it, and put a number on it. You keep the evidence pack.
WHAT YOU LEAVE WITH
An evidence pack. One specific discrepancy, quantified in currency or units, linked to the source record, the rule and the calculation that produced it, pinned to the moment it was found so it still reconstructs months later when the source record has changed.
It is yours. Exportable, readable without our platform, and it survives this conversation ending.
Or a clean result. If the systems agree, you learn something worth knowing about your own estate and it cost you an afternoon.
HOW IT ENDS
Three honest outcomes:
We find something material. We tell you what a pilot would look like, priced as a share of the value it delivers rather than seats or modules. You decide.
We find something small. We say so. A finding worth four thousand dollars is a finding, and it is not a business case.
We find nothing. We say that too, and we tell you why we think that is: usually a single-system estate or unusually disciplined master data. Both are compliments.
There is no version of this where we tell you it went well when it did not. The entire product is an argument that claims should carry evidence, and it would be a strange thing to abandon in the first meeting.
THE QUESTIONS YOUR TEAM WILL ASK
"What happens to our data?" It stays in your environment. Nothing leaves unless you connect something that takes it there, and the platform tells you which class of data went where.
"What if we stop?" Your systems of record remain authoritative because we never became one. There is nothing to migrate back.
"Who sees it?" Whoever you name. Nothing is published, referenced or used as a case study without written approval.
"How is this different from what our BI team could do?" Your BI team can compare two extracts. The difference is what happens next: a rule that is versioned, evidence that is pinned to the moment, a decision recorded with the alternatives rejected, and an outcome measured against what the decision expected. The comparison is the easy part.
TO START
Reply with two systems and one domain. We will send back the field-level access list within a day.
founder@assetshopenterprise.com
EOS, delivered under the AssetShop brand by Web3 Ventures Enterprise. Nerio reads every system of record; Minerva writes only on a named approval.