Tentatively Reconciled Event

Overview

A tentatively_reconciled event is sent when objects are matched to a pending Transaction. A reconciled or completed event is sent when objects are matched to a posted Transaction.

Note that tentatively_reconciled is an event, and not a state change. When a tentatively_reconciled event is sent, the corresponding object will be in a pending state (e.g., sent for Payment Orders).

Each customer is responsible for the business decisions it takes based on these events. Taking actions or building business logic based on pending transactions has inherent risks. Please review Building for Resiliency Best Practices below and evaluate the tradeoffs and risk tolerances for your own business.

Posted vs. Pending Transactions

A posted Transaction is a transaction that has been fully processed and completed. They are immutable records. Posted transactions provide full certainty of account activity, and are typically reported at the start of the next business day.

A pending Transaction is a transaction that is in progress and has not been fully processed yet; they are allowed to change on a banking ledger (e.g., the description or amount could change, or it could be cancelled). Pending transactions provide early signals of account activity because they are reported intraday and are often equivalent to the posted transactions.

However, there are cases where no pending Transaction precedes posted activity, or where the pending Transaction is meaningfully different than the subsequently posted Transaction. For example, this may happen if a bank flags suspicious activity for additional screening or rejects transactions due to OFAC (Office of Foreign Assets Control) review.

In the dashboard, posted and pending Transactions are denoted by the Transaction status.

To utilize pending Transactions, you will need to configure your bank and Modern Treasury accounts to enable intraday reporting. Pending Transactions are archived when its replacement posted Transactions become available. Because pending Transactions may change or have different data, they are not linked to posted Transactions.

The tentatively_reconciled Event

Modern Treasury automatically and continuously evaluates all pending and posted Transactions for possible reconciliation with Payment Orders, Incoming Payment Details, Expected Payments, or Returns.

When an entity is reconciled, Modern Treasury sends webhook events:

• tentatively_reconciled when matched to a pending Transaction
• reconciled or completed when matched to a posted Transaction.

Refer to the webhook events documentation for specific examples and additional events: Payment Orders, Incoming Payment Details, Expected Payments, Returns.

Example of Payment Order tentatively_reconciled event:

{
  "event": "tentatively_reconciled",
  "data": {
    "accounting_category_id": null,
    "amount": 123100,
    "charge_bearer": null,
    "counterparty_id": "928db55e-6552-4aaf-96d7-10c693922b1f",
    "created_at": "2025-01-12T22:27:22Z",
    "currency": "USD",
    "description": null,
    "direction": "credit",
    "effective_date": "2025-01-13",
    "foreign_exchange_contract": null,
    "foreign_exchange_indicator": null,
    "id": "9f7e0efa-aeb7-4378-ae18-b4bb038e5495",
    "metadata": {},
    "object": "payment_order",
    "originating_account_id": "b9fc1ae0-d493-4f01-a7b3-b39104e802b5",
    "priority": "normal",
    "receiving_account": {
      "account_details": [
        { ... },
      ],
      "account_type": "checking",
      "created_at": "2025-01-21T22:51:04Z",
      "id": "71fae619-afa6-45e6-8630-ce4d0b3d6387",
      "intermediate_account_id": null,
      "object": "external_account",
      "party_address": null,
      "party_name": "John Smith",
      "party_type": null,
      "routing_details": [
        { ... },
      ],
      "updated_at": "2025-01-21T22:51:04Z",
      "verification_status": "unverified"
    },
    "receiving_account_id": "71fae619-afa6-45e6-8630-ce4d0b3d6387",
    "receiving_account_type": "external_account",
    "remittance_information": "December Rent",
    "statement_descriptor": "Rent",
    "status": "sent",
    "transaction_ids": [],
    "type": "ach",
    "transaction_monitoring_enabled": false,
    "decision_id": null,
    "updated_at": "2025-01-12T22:27:25Z"
  }
}

Use Cases

Building for Resiliency Best Practices

There are key differences and technical nuances that need to be considered when using intraday payment activity data. We suggest these best practices when building solutions using the tentatively_reconciled webhook event.

Handle both tentatively_reconciled and completed events (or reconciled if using Expected Payments).

Intraday reporting that generates pending Transactions may be less consistent than end-of-day or prior day reporting for posted Transactions. For example, some transactions will never be pending. Or some transactions may have missing, malformed, or more abstract data than what will eventually be on the posted bank transaction. As a result, the tenatively_reconciled event may be less predictable or consistent than completed or reconciled events.

To ensure you have the final picture of settled payment activity, you should process both pending and posted Transactions events by handling both types of events in your application. You should ensure that your internal processing is idempotent so that you only process a payment's updated state once. For example, if you receive both a tentatively_reconciled and a completed webhook for received funds, you should only credit funds to a user once.

Decide how to treat fund availability of pending vs. posted Transactions

The tentatively_reconciled event and pending Transaction signals that your bank or payment processor is providing visibility to in-progress activity in your account, but it's important to understand that these signals remain tentative. Depending on the payment method, this may not guarantee that the transaction will fully clear or settle, and does not guarantee that the funds or balance will eventually become available.

Depending on your business, fund flow, or payment method, you may have different risk tolerances for making funds available for downstream activity based on on these events. For example, some companies may choose to disburse funds based on the receipt of a pending ACH credit, but this has inherent risks because the transaction may not ultimately complete. Others will choose to wait until a fully settled credit transaction. You should decide what is triggered by the tentatively_reconciled event vs. completed (or reconciled) based on your business’s needs, risk tolerances and tradeoffs. Each customer remains solely responsible for the actions it takes, or business logic it follows based on pending or posted transactions.