Digits: source transactions versus the ledger
How Digits separates imported records from accounting results, and why source identity, replay and ledger visibility are different concerns.
- Source identity
- Processing and matching
- Ledger result
Investigation question
When an integration successfully writes a financial record, what has actually become true? This investigation separates acceptance of source data from the existence of an accounting result, then follows the identity needed to reconcile the two.
Observed
The public Source vs Ledger guide describes two layers: independent source streams retain upstream records, while the ledger presents a merged accounting view. Source writes and ledger reads therefore describe different stages of the contract. The guide also describes eventual visibility between those stages. A successful source request should not be interpreted as a synchronous promise that a corresponding ledger transaction can already be read. The Identifiers guide makes source identity operational: an external identifier belongs to a source-specific key space. Repeated writes for that identifier refer to one object; sync endpoints use the most recent submitted properties. Digits-provided IDs identify records inside the accounting system. These are different identifiers with different ownership.
Inferred
The useful architectural boundary is provenance versus interpretation. Preserving the upstream identity gives a client something stable to replay and investigate, while the accounting layer can combine evidence from multiple origins. It does not follow that every source record produces exactly one ledger transaction. For example, a payment-processor payout and a bank deposit can describe one economic movement. Matching them is a separate question from deduplicating a retry of the processor record. Treating both situations as the same kind of duplicate would confuse transport reliability with accounting reconciliation.
Unknown & limitations
This is a static analysis of the cited public contract, not a measurement of a connected business account. No money, ledger or live integration was changed. Processing latency, matching heuristics, race behavior and correction propagation were not reproduced. The guides support the two-layer model; they do not establish the internal database, queue technology or a universal one-to-one mapping. Treat those implementation details as unknown.
Domain & data models
Illustrative identity model: (source, external ID) identifies an imported object; a ledger ID identifies an accounting result. Retain both when building an audit trail. Do not replace the external ID with the ledger ID or assume equal ID strings from two sources name the same object.
Workflows & state machines
Worked example, not a production trace: an importer reads upstream payout P-104, writes it using the same external identity on retries, and records that source acceptance succeeded. A separate read checks the resulting ledger state. If the ledger result is not yet visible, the importer can report “accepted; accounting result pending” instead of inventing another payout. A focused verification would replay the same source identity, change an allowed property through the documented sync contract, and observe ledger visibility separately. Record the request outcome and later read outcome as two pieces of evidence. The acceptance criterion is identity stability, not an assumed fixed processing delay.