How TransactIG Delivers Results
Reconciliation as deterministic infrastructure, not a black-box score. One canonical envelope per run, four buckets of Discovered Money, and money delivered as exact decimal strings — the same contract whether you consume it in a dashboard or straight from an API.
Deterministic reconciliation infrastructure
TransactIG is deterministic. The same inputs and the same configuration always produce a byte-identical output. This is the audit-grade property that makes the result usable as evidence — not just information. Results are reproducible; they are not a black-box score.
The practical meaning: an auditor who wants to re-run last quarter — six months from now, a year from now — can point TransactIG at the same input files under the same organisation configuration and get back the same envelope, byte for byte. Every figure, every classification, every exception narrative. Nothing drifts because the wall-clock changed, nothing is regenerated by a probabilistic step, nothing depends on a model checkpoint that has since moved on.
Determinism is stated up front because it is the foundation for everything else on this page. When we say "the envelope is the single source of truth," we mean a source that is stable across time. When we say "money is a contract, not a hope," we mean a contract that will still hold on the day a regulator or a board finance committee asks for it.
The Recon Output Envelope
Every reconciliation run produces one canonical, machine-readable result: the Recon Output Envelope. It is a versioned JSON document that carries everything a finance team or a downstream system needs from a run — what was reconciled, what tied out, what money was found, and the evidence trail that supports every figure.
The envelope is deliberately one document, not a scatter of endpoints. Its manifest records the run's identity — organisation, period, input files with fingerprints, configuration and engine versions. Its integrity block states the accounting identities that were checked and whether they held. Its discovered money block carries the headline number and the four-bucket split. Its module entries carry the working papers for each reconciliation stream. Its provenance points every figure back home.
The envelope's schema version is "1.0".
It is additive-only within a major version: fields are added, never renamed or removed. For the
full section-by-section reference — including a worked example with illustrative figures — see
the Recon Output Envelope reference.
Four buckets — the same across every run
Every run classifies its findings into four buckets. The bucket determines the workflow — who acts, on what timeline, and against which counterparty. The four categories are the same across every industry preset, so a CFO reading the envelope from any run knows exactly what each column means.
Recoverable
Money you can get back.
TDS credits waiting to be claimed, over-charged platform fees, mis-routed refunds. Every item is tagged with the specific recovery path — file a rectification, raise a merchant ticket, reissue a chargeback.
Stuck
Money delayed in process.
Invoices sitting in a customer's approval queue past agreed payment terms; settlements held by a payment gateway pending resolution. Ageing is measured against the contractual terms your team configured, not against a generic default.
At-risk
Money exposed to loss.
Invoices approaching the statutory ITC-reversal deadline; disputed line items without an evidence trail. Every at-risk item carries the deadline that makes it at-risk and the action window remaining.
Compliance
Statutory exposure or disclosure.
GST liability arising from valuation-rule treatment errors on trade schemes; TDS shortfall requiring rectification. These items are flagged because a regulator, not a counterparty, is the interested party.
The dashboard displays these four buckets in cards; the envelope carries them in the
discovered_money
section as structured data with a per-stream breakdown and the individual items behind each
headline. The classification is applied by the engine — a finance team cannot recategorise a
Compliance item into a Recoverable one to close it faster, and vice versa. Discovered Money is
not a queue; it is a stratified view of where money currently sits and what action each stratum
demands.
Two consumption modes, one contract
There are two ways to consume the envelope. The first is dashboard-first: finance teams work in the TransactIG UI — the four Discovered Money cards, the module views, the exception drawers, the export buttons. The second is integration-first (headless): results are delivered straight into ERP, CRM, or downstream workflow systems by the envelope API or by an equivalent per-run file artifact placed in the organisation's secure file area.
Both modes read from the same envelope. There is no separate "API version" of the truth
and "screen version" of the truth. The dashboard is a rendering of the envelope; the
integration is a consumption of the envelope. When a screen shows a variance of
₹1,25,000.00 in a specific exception drawer, the envelope carries
"125000.00"
as the same value in the corresponding module row. Illustrative — but the equivalence is the point.
Most enterprise deployments use both modes concurrently: finance teams work in the dashboard for exception review and drill-down, while the envelope flows into ERP for posting-side workflows, into a data warehouse for board reporting, and into audit workpapers for evidence attachment. One envelope; several consumers; identical figures on every screen.
Precision is a contract
Every money value in the envelope is delivered as an exact decimal string — never
a floating-point number. A value of twelve lakh fifty thousand rupees ships as
"1250000.00"
(a JSON string in quotes), not as
1250000
(a JSON number). Precision is a contract, not a hope.
This convention matters because IEEE-754 floating-point representation cannot express every decimal value exactly. A currency amount that survives ingest as a clean decimal can silently drift by fractions of a paisa the moment it passes through a floating-point step in an integrating system — and drifted paisa in a sum of ten lakh rows become a variance no auditor accepts. The decimal-string convention removes that class of error at the contract boundary.
If you are parsing the envelope, never coerce a money field through binary floating
point. Read every money field as a string and hand it directly to a decimal library —
decimal.Decimal
in Python,
BigDecimal
in Java or Kotlin,
decimal.js
in JavaScript, or the platform equivalent. Auditors need this; engineers writing to ledgers
need this; the envelope guarantees it.
The rest of the developer documentation
This page is the concepts primer. The three companion pages go deeper on the envelope itself, the input side, and the integration process.
The Recon Output Envelope
Section-by-section field reference with a worked example. The one endpoint, the two error codes, the schema version, the money-as-string convention.
Getting data in
The file formats TransactIG ingests, the delivery mechanisms (upload, SFTP, API), and how the onboarding process maps your exact file shapes once.
The integration process
Six stages from discovery to go-live and expansion. What we ask you for, and what you receive at each stage.
Ready to see the envelope on your own reconciliation?
Every TransactIG deployment is deterministic from day one. ISO 27001:2022 certified. Configured, not coded — no application development required to go live.