Reconciliation at Cobre

Matching every payment to your books, automatically or on demand

Reconciliation is how you confirm that the money you expected to move actually moved — and tie it back to the invoice, order, merchant, or account it belongs to. Cobre's platform is built so that every payout, collection, and balance movement carries the identifiers you need to close that loop, whether you check it in real time, query it on demand, or process it in bulk at the end of the day.

1. What Cobre Enables with Reconciliation

Match every payout and collection to the internal record that triggered it, without manual lookups

Confirm a Cobre Balance's opening balance, closing balance, and daily totals independently of individual payment reconciliation

Detect and explain rejections and failures with structured reason codes, instead of a plain "it didn't work"

Reconcile collections that never generate a Money Movement — static payment keys, virtual account numbers, and standing bank references — using the reference field each one carries instead

Track fund consolidation across linked balances (Primary/Secondary accounts) as a single, correlated chain

Choose the reconciliation method that fits the moment: real-time webhooks, on-demand API queries, or bulk reports

2. Reconciliation in the Cobre Model

Every payment on Cobre's platform produces two related but distinct objects: a Money Movement, which represents the payment intent and its lifecycle status, and one or more Transactions, which are the actual entries that move your Cobre Balance. Reconciliation is the discipline of tying these back together — and, for the collection methods that never create a Money Movement, tying the resulting Transaction back to whichever standing reference received it.

Not every collection method works the same way. Some — Direct Link, Checkout, Request to Pay — represent a specific request Cobre tracks from creation to completion, so the resulting Transaction always carries the Money Movement's identifier. Others — a static Cobre Key, a Virtual CLABE, a Transfer-In account — are standing references that can receive funds at any moment, with no request behind them, so they carry their own reference field instead. Knowing which category a payment belongs to is the first step to reconciling it correctly.

3. Key Capabilities

3.1 Money Movement–Based Reconciliation

For payouts and for collections initiated through a specific request (Direct Link, Checkout, Request to Pay, Direct Debit), the resulting Transaction carries the originating Money Movement's identifier. This is the simplest case: query the Money Movement for its lifecycle status, and match the Transaction back to it directly.

3.2 Reference-Based Reconciliation

Static Cobre Keys, Virtual CLABEs, CLABE-linked balances, and Transfer-In account references don't represent a specific request — they're standing destinations that can receive funds from anyone, at any time. Because there's no request to track, no Money Movement is created. Instead, each Transaction carries the reference that received it, and that reference is your reconciliation key. Issuing one reference per customer or merchant gives you per-entity attribution without any extra bookkeeping.

3.3 Balance-Level Reconciliation

Beyond individual payments, Cobre gives you the opening balance, closing balance, and total credits/debits for a Cobre Balance on any given day — either by deriving them from the day's Transactions yourself, or by reading them already computed. This is the checkpoint that lets finance teams confirm a period closed cleanly, independent of how many individual payments made it up.

3.4 Account Linkage Reconciliation

When a Cobre Balance is configured to automatically sweep every credit it receives to a primary balance — common when a business receives collections into several balances but consolidates liquidity in one — Cobre generates a fully correlated chain for every sweep: the original credit, the automatic transfer, and the resulting debit and credit on each side. That chain is designed to be traced end to end, so consolidation never becomes a black box.

4. Core Concepts and Terminology

Money Movement: The object representing a payment's intent and lifecycle status (e.g. initiated, processing, completed, rejected, failed, canceled).

Transaction: The ledger entry that actually debits or credits a Cobre Balance. A Money Movement can produce zero, one, or more Transactions depending on how its lifecycle unfolds.

Reconciliation key: The field you match a Transaction against — the Money Movement's identifier for request-based payments, or the standing reference (a Cobre Key, a CLABE, a Transfer-In account) for reference-based ones.

Reason codes: The structured code and description Cobre attaches to a rejected or failed Money Movement, explaining why it didn't complete.

Opening / closing balance: The balance at the start and end of a given day for a Cobre Balance, derived from — or matching — that day's Transactions.

Account linkage: The configuration that automatically forwards every credit a secondary Cobre Balance receives to a primary one.

5. Speed, Settlement & Reliability

Money Movement status changes and Transactions are available for real-time reconciliation via webhooks, typically within seconds of the underlying event. Some payouts can complete and only later be reported as rejected if the destination bank returns the funds after the fact — Cobre reverses the balance impact automatically when that happens, but it means a completed status shouldn't be treated as permanently final without a final reconciliation pass. Webhook delivery itself is best-effort: on-demand queries and bulk reports are the periodic fallback that catch anything a webhook missed. Balance-level figures for a full day are only finalized a few hours after the day ends, once all of that day's activity has settled.

6. Typical Business Use Cases

Confirming a payout landed with the beneficiary before releasing goods, services, or a subsequent step in a workflow

Attributing incoming collections to the right customer or merchant when using shared or per-entity payment references

Closing out a daily or monthly finance period by validating a Cobre Balance's totals against internal records

Consolidating collections received across multiple balances into a single operating balance, with full traceability of every sweep

Feeding an ERP or ledger system with structured, machine-readable payment and balance data instead of manual bank statement review

These use cases share a common need: certainty about what happened to a specific payment or balance, without waiting on a human to check a bank portal.

7. Transactions, Reporting & Reconciliation

Cobre supports three complementary ways to reconcile, so you can pick the right one for the situation:

Real time, via webhooks on Money Movement status changes and account balance credits/debits — the fastest signal, best-effort in delivery.

On demand, via API queries filtered by status, date range, external reference, or counterparty — best for checking a specific payment or a small batch.

In bulk, via downloadable reports covering Money Movements, Transactions, or both over a date range — best for period-end reconciliation or high volumes.

Every Transaction Cobre generates includes the fields needed for at least one of these reconciliation keys — the Money Movement identifier, or the standing reference of the account, key, or CLABE that received the funds — so no payment is left unattributable.

8. Governance, Controls & Auditability

Every Money Movement and Transaction is timestamped and immutable once recorded, giving finance and compliance teams a durable audit trail. Reason codes on rejected or failed Money Movements provide a documented explanation for exceptions rather than a silent gap. Account linkage sweeps preserve full traceability between the original collection and the consolidated balance, so internal audits can always answer "where did this money originally come from."

9. Reconciling by Money Movement vs. Reconciling by Reference

Dimension	Money Movement–based	Reference-based
Applies to	Payouts, Direct Link, Checkout, Request to Pay, Direct Debit	Static Cobre Keys, Virtual CLABEs, CLABE-linked balances, Transfer-In
A Money Movement is created	Yes	No
Reconciliation key	Money Movement identifier	The standing reference itself (key, CLABE, or account reference)
Best for	Attributing a specific, one-time request	Attributing a standing collection point that can be paid at any time
Granularity	Per transaction	Per entity holding the reference — issue one reference per customer for per-customer granularity

10. Summary — What Cobre Delivers with Reconciliation

A consistent set of reconciliation fields across every payment method, whether it's backed by a Money Movement or not
Three ways to reconcile — real time, on demand, or in bulk — so teams can match the method to the need
Structured reason codes for rejections and failures, instead of ambiguous outcomes
Balance-level checkpoints that close out a period independently of individual payment reconciliation
Full traceability for consolidated balances under account linkage

Reconciliation on Cobre is designed so that no payment — however it arrived — is ever a mystery on your books.

Reconciliation at Cobre

Matching every payment to your books, automatically or on demand#

1. What Cobre Enables with Reconciliation#

2. Reconciliation in the Cobre Model#

3. Key Capabilities#

3.1 Money Movement–Based Reconciliation#

3.2 Reference-Based Reconciliation#

3.3 Balance-Level Reconciliation#

3.4 Account Linkage Reconciliation#

4. Core Concepts and Terminology#

5. Speed, Settlement & Reliability#

6. Typical Business Use Cases#

7. Transactions, Reporting & Reconciliation#

8. Governance, Controls & Auditability#

9. Reconciling by Money Movement vs. Reconciling by Reference#

10. Summary — What Cobre Delivers with Reconciliation#