Versioning, Determinism & Audit Guarantees
Five commitments the envelope makes to auditors, risk teams, and integration engineers. Each is a property of the delivered artifact — not a promise about future behaviour.
Five properties of the artifact, not five promises about it
Reconciliation output is evidence. It lands in front of statutory auditors, internal auditors, risk committees, and — sometimes — regulators. That reality shapes every commitment on this page.
The five commitments below are not aspirations. They are properties of the envelope you receive. Each is testable by inspection of the JSON bytes on your side of the wire, with no cooperation required from us.
Determinism. Versioning. Precision. Evidence. Isolation.
One property per section. Each stated in the vocabulary an auditor, a risk lead, or an integration engineer would use.
Determinism
Same inputs and the same configuration produce a byte-identical envelope. Re-running last quarter reproduces last quarter — the same JSON bytes, the same fingerprints, the same figures.
This is why an auditor can accept the envelope as evidence rather than as a report. A report is a rendering of a moment in time; the envelope is the moment itself, preserved.
Versioning
The envelope carries a schema_version field ("1.0" today). Changes within a major version are additive-only — new fields may be added, but existing fields are never renamed or removed.
Integrations pinned to schema version 1 will keep working through 1.x additions. Any future major version bump would be a deliberate, communicated breaking change — never a silent one.
Precision
Money values are exact decimal strings end-to-end. The envelope you receive over the API is the same envelope written to your file area is the same set of bytes an auditor can hash.
No floating-point money enters the delivered artifact. Parsers that coerce money through binary floating point produce a different reconciliation than the one signed off — same figures on the wire, different figures on the desk.
Evidence
Inputs are fingerprinted in the manifest — per-file content hashes tying each input to the run. Every exception in modules[].exceptions carries a plain-language narrative in the customer's vocabulary, not an internal code lookup.
Deep evidence — the proof trail behind each figure — is available via opt-in drawer_payloads[]. Off by default; enable it when your workflow wants the full computation waterfall alongside the summary.
Isolation
API-key-scoped, everything. Cross-organisation access is structurally impossible — not policy-discouraged, not access-controlled by role, structurally impossible.
An unknown run_id and a run_id belonging to another organisation both return the same 404 RUN_NOT_FOUND, because revealing the difference would leak tenant existence. The error semantics are deliberate.
Money is always a decimal string. Never coerce it through binary floating point.
A field like "discovered_money.total": "1250000.00" is a string, in quotes, deliberately. If your parser calls a generic JSON.parse that coerces money to a JavaScript number or a Python float, you now hold a different figure than the one an auditor signed off — and the mismatch will not surface until quarter-end.
Parse money values as strings. If arithmetic is required downstream, use a decimal library (Python decimal.Decimal, JavaScript Big.js, Java BigDecimal). The envelope's precision contract only holds if your parser preserves it.
Why an unknown run and someone else's run return the same error
A run identifier you have never seen and a run identifier belonging to another organisation both return 404 RUN_NOT_FOUND. This is not a bug; it is the isolation contract.
If cross-tenant identifiers returned a distinguishable error code, for example — the API would confirm the existence of runs in other organisations. That confirmation is itself a leak of tenant metadata. The uniform 404 exists so that the shape of the API cannot be probed to enumerate tenants.
The second published error, 404 OUTPUT_CONTRACT_DISABLED, is returned when your organisation exists but envelope delivery is not yet enabled — it is opt-in per tenant, and your onboarding manager enables it. Everything else that could go wrong resolves to the same 404 by design.
Why teams that need an audit-defensible reconciliation choose TransactIG over general-purpose ETL
These five commitments — determinism, additive-only versioning, decimal-string precision, fingerprinted evidence, and structural isolation — are the difference between a reconciliation that reads like a report and one that stands as evidence. General-purpose ETL can move rows. It cannot make them audit-defensible on the far side of the pipeline. That is what the envelope contract is for.