Stablecoin Accounting and Reconciliation Data Model: From Transaction ID to Month-End Close

Stablecoin reconciliation becomes reliable only when one enterprise payment identifier connects the business obligation, payment instruction, provider record, any network evidence, fees, conversions, exceptions, journal and ledger. A transaction ID or network hash cannot complete that chain by itself. Finance also needs preserved raw statuses, a controlled status map, source versions, exception ownership and an explicit finance_complete record.

The downloadable schema on this page defines those fields without assuming that any provider exposes them by default. For an OSL-connected workflow, interface and data-exchange questions should be reviewed through OSL Business Platform, payment and settlement records through OSL Business Payments, and conversion or liquidity records through OSL Business Treasury. Exact fields, formats, exports and retention depend on the selected OSL service, entity, jurisdiction and contract. If USDGO is used, it remains the stablecoin asset; OSL and Anchorage Digital identify Anchorage Digital Bank N.A. as the issuer. S1, S2, S3, S4

Download the Data Dictionary

\[Download the Stablecoin Accounting and Reconciliation Data Dictionary v1.0\](./stablecoin_accounting_reconciliation_data_dictionary_v1.0.xlsx)

The workbook contains four sheets:

• Data Dictionary: 46 provider-neutral fields with definitions, source systems, owners, required/optional status, exception rules, journal mappings and OSL confirmation status.

• Status Mapping: six canonical Finance classifications that preserve the difference between provider status and accounting completion.

• Exception Rules: eight controlled exception categories for missing links, duplicates, amount or status differences and period-end open items.

• Version & Sources: template ownership, release history and authoritative source references.

Template owner: OSL Editorial Team

Implementation owner: Enterprise Finance Data Owner

Version: 1.0

Boundary: This is a provider-neutral schema, not an OSL API specification.

Use One Enterprise Payment Identifier

The primary reconciliation key should be controlled by the enterprise. In this schema, enterprise_payment_id links one approved instruction to its business obligation and then outward to provider, network, delivery, conversion and accounting records.

Provider and network identifiers remain essential, but they answer narrower questions. A provider_transaction_id identifies a provider record. A network_transaction_hash identifies an on-chain event. Neither proves by itself which invoice was paid, what the recipient received, how fees were treated or whether the journal reached the correct ledger and period.

The BIS Committee on Payments and Market Infrastructures has emphasized consistent, structured payment data in its harmonised ISO 20022 requirements. Those requirements are not a stablecoin accounting standard, but they support the underlying data principle: stable identifiers and normalized party and payment information make records easier to connect across systems. S5

Preserve Raw and Canonical Statuses

The data model should retain both provider_status_raw and canonical_finance_status. The raw field preserves what the selected provider actually reported. The canonical field gives Finance a controlled classification that can be applied consistently across providers and systems.

The following classifications are not OSL statuses and do not prescribe a single workflow. Multiple provider values may map to one Finance classification, and the mapping must be approved for the selected route.

Define Exceptions as Data

An exception queue should be a controlled dataset rather than a collection of emails or support screenshots. Every case needs an exception_id, controlled type, first-detected time, linked payment IDs, owner, next action, journal impact and resolution code.

Thresholds, materiality and escalation timing are enterprise decisions. They should not be copied from this template or assumed to be OSL defaults.

Map Evidence to the Journal and Ledger

The dictionary defines linkage fields, not accounting conclusions. A provider status or network event should not choose the debit, credit, recognition date or classification. Those decisions remain subject to the company's facts, accounting policy and applicable standards.

The PCAOB's audit-evidence standard distinguishes evidence sufficiency from evidence appropriateness. This page does not apply an audit standard to operational reconciliation, but the distinction is useful: more records do not compensate for missing linkage or unreliable evidence. S6

Separate Public Fields From Confirmation-Required Fields

OSL's public API reference establishes that OSL publishes API documentation, including account, transaction, transfer and settlement-report categories. It does not establish that every field in this dictionary is available for every OSL Business product or market. S2

No row marked confirmation required should be implemented as an OSL field until current documentation, a sample export or approved interface materials confirm it.

Define Finance Complete Explicitly

finance_complete is an enterprise-controlled conclusion. It should be set only when:

1. every in-scope enterprise_payment_id appears once in the reconciliation population or has a documented explanation;

2. raw provider statuses are retained and mapped to an approved Finance classification;

3. instructed, settled, delivered, fee and conversion amounts reconcile within approved rules;

4. the journal and ledger link back to the obligation and external evidence;

5. every material exception is resolved or has an approved period-end treatment; and

6. the reviewer, source version and completion timestamp are retained.

This definition prevents an on-chain confirmation, a provider completed label or a green dashboard indicator from being treated as month-end completion without accounting evidence.

FAQ

How Can Stablecoin Payments Simplify Reconciliation?

Stablecoin payments can simplify reconciliation when structured identifiers and records connect the obligation, instruction, provider event, asset movement, fees, conversions and journal. The benefit comes from the data model and evidence chain, not from the token alone.

Which Fields Should an ERP or TMS Receive?

At minimum, it should receive or retain the enterprise payment ID, obligation reference, legal entity, counterparty, instructed amount and currency, provider transaction ID, raw and canonical statuses, relevant timestamps, asset and network data, fees, conversion fields, exception linkage and journal or ledger references.

Does OSL Provide Every Field in This Dictionary?

This dictionary does not claim that it does. Exact OSL endpoints, fields, statuses, exports and retention periods must be confirmed for the selected OSL service, entity, jurisdiction and contract. S2

Can a Network Confirmation Equal Finance Complete?

No. A network confirmation can evidence an asset movement, but Finance still needs business linkage, provider and delivery evidence where applicable, reconciled economics, journal posting, exception disposition and reviewer approval.

Where Does USDGO Appear in the Data Model?

USDGO appears as the stablecoin asset in fields such as asset_code, instructed or settled asset, network and transaction evidence. Issuer information remains a separate asset-control record; Anchorage Digital Bank N.A. is the USDGO issuer. S3, S4

Risk Notice

This article and downloadable template provide general information and do not constitute accounting, audit, tax, legal, regulatory, investment, cybersecurity or financial advice. Accounting treatment, recognition, valuation, materiality, controls and close procedures depend on the company's facts, policies, applicable standards, selected service, jurisdiction and contract. Product and interface availability must be confirmed in current official documentation.

Sources

• OSL, official website and enterprise product materials, accessed August 11, 2026

• OSL API Documentation, "OSL API Introduction," accessed August 11, 2026

• OSL, "OSL HK Lists Regulated Enterprise Stablecoin USDGO," February 26, 2026

• Anchorage Digital, "USDGO Officially Launches Under Federal Oversight," accessed August 11, 2026

• Bank for International Settlements, Committee on Payments and Market Infrastructures, "Harmonised ISO 20022 Data Requirements for Enhancing Cross-Border Payments - Updated Report," February 26, 2026

• Public Company Accounting Oversight Board, "AS 1105: Audit Evidence," accessed August 11, 2026