Real-Time Settlement and Instant Payment Accounting: How FedNow and ISO 20022 Change Bank Reconciliation

Your business can send a payment at 11:47 p.m. and have the recipient use the money seconds later. Your bookkeeping process may still be waiting for tomorrow’s bank feed, a processor report, or a human to decide which invoice the payment belongs to.

That gap is the accounting challenge of instant payments. Faster settlement does not remove the need for reconciliation; it changes what you reconcile, when you reconcile it, and which evidence you retain. FedNow and the RTP network make real-time payment rails available through participating financial institutions, while ISO 20022 supplies structured messages such as payment instructions, status reports, notifications, and remittance details.

For a small business, the goal is not to implement a bank’s entire messaging stack. It is to ensure that every payment has a clear lifecycle, a unique reference, a correctly timed accounting entry, and an exception owner.

What changes when settlement happens in real time​

Traditional ACH and check workflows create familiar timing gaps. You approve a payment today, a batch is submitted later, the bank processes it on a schedule, and the recipient sees the funds after another delay. Those gaps create a useful, if imperfect, space for review and correction.

Instant payment networks operate continuously. FedNow is designed for real-time payments around the clock, every day of the year. The RTP network also supports immediate transfers and message exchanges. A payment can therefore settle outside your normal accounting hours, when the person who approves invoices, the bookkeeper, and the bank-feed process may all be offline.

That creates four practical changes:

1. The calendar is no longer a control. A transaction does not wait for Monday’s payment run or the end of a banking day. Your approval limits, alerts, and review queue must work at night, on weekends, and on holidays.
2. A bank balance can change before your books do. If your accounting system imports statements once a day, a settled payment may sit unmatched for hours even though cash has already moved.
3. A payment request is not the same as a settlement. An instruction can be rejected, timed out, returned, or held for review. Posting an expense or receipt as soon as someone clicks “send” can create false cash and incorrect liabilities.
4. The reference data matters more. A transaction amount and date are not always enough to identify the invoice, customer, project, or legal entity. Structured remittance data can improve matching, but only if you preserve and map it.

The result is a shorter settlement window but a larger need for event-level bookkeeping.

FedNow, RTP, and ISO 20022 are different things​

These terms often appear together, but they describe different layers of the payment process.

ISO 20022 is not an accounting standard and does not decide when your business recognizes revenue, an expense, or a payable. It also does not replace your bank’s product configuration. Your financial institution or payment provider decides which fields are available to your software and how they appear in an export or API.

Some message types are useful when designing a reconciliation map. A customer credit transfer may be represented by pacs.008; a status response by pacs.002; a return by pacs.004; and account reporting may use messages such as camt.052, camt.053, or camt.054. You may never see the raw XML, but asking your provider which business identifiers survive into statements, notifications, and reports is still worthwhile.

Model the payment lifecycle before choosing an account​

The cleanest reconciliation process starts with states rather than a single “paid” flag. At minimum, record these events:

1. Approved​

An authorized person approves the payment. The approval should identify the vendor or customer, amount, currency, invoice or contract, destination account, approver, and reason for urgency. Approval is evidence of intent; it is not evidence that cash has moved.

2. Submitted​

The bank or provider receives the instruction. Save the provider’s request identifier and your own payment reference. If a network or API supports an idempotency key, use a stable value so a retry does not accidentally create a second payment.

3. Accepted or rejected​

The response tells you whether the instruction passed the provider’s initial validation. A rejected item should move to an exception queue, not silently disappear. A successful submission may still need a separate settlement confirmation.

4. Settled​

Settlement is the point at which you should normally clear the payment from a bank-clearing account into the actual bank account, subject to the information your institution provides. Store the network reference, settlement timestamp, counterparty, amount, and any remittance data.

5. Returned or adjusted​

Instant payment does not mean that every mistake is impossible to address. Networks provide return and investigation messages, but the process is not identical to a card chargeback. A returned payment needs its own entry and an explanation of whether the original payable, receivable, fee, or cash entry is being reinstated.

This event history prevents a common error: treating an API response, a notification, and a statement line as three separate payments. They are often three views of one payment.

A practical chart-of-accounts pattern​

You can adapt the names to your existing ledger, but keep the roles distinct:

• Operating bank account: the account that actually receives or releases settled cash.
• Instant-payment clearing: a temporary account for submitted items whose final settlement evidence has not yet been matched.
• Payment fees: a separate expense account for per-transaction or provider charges.
• Accounts payable or accounts receivable: the liability or asset that the payment settles.
• Returns and adjustments: a visible account or workflow label for returned funds, rejected payments, and unresolved corrections.

For an outbound supplier payment, the business event may be recorded before payment: debit the appropriate expense or inventory account and credit accounts payable when the invoice is approved and goods or services are received. When the payment is initiated, move the amount from the operating bank account or payment clearing account according to your policy and the provider’s actual timing. When settlement is confirmed, clear the temporary balance against the bank statement.

For an incoming customer payment, match the settlement to the open receivable, not merely to a deposit amount. If the payment arrives without enough remittance information, leave it in an unapplied-cash account until someone identifies the customer and invoice. Do not improve a reconciliation percentage by guessing.

The important design decision is to make unmatched states visible. A clearing balance that remains open for 48 hours should be reviewable; a balance hidden inside a generic “miscellaneous” account is much harder to control.

Build the reconciliation around identifiers​

Real-time payments are easiest to reconcile when your internal reference travels with the payment. Before implementation, ask your bank or provider about each field below:

• Your payment or instruction ID.
• The bank or network reference.
• The invoice, customer, or vendor reference.
• The ultimate debtor and creditor, if different from the account holders.
• Value date and precise settlement timestamp.
• Payment status and return reason.
• Remittance information and any request-for-payment reference.
• Fees, taxes, currency, and exchange-rate information.

Then define a matching hierarchy. An exact invoice reference plus amount is strongest. A stable payment ID is next. Counterparty, currency, amount, and a narrow date window can support an automated suggestion, but they should not override a conflicting invoice reference.

Keep the original message or report alongside the normalized accounting record where possible. A parsed field is useful for automation; the unmodified evidence is useful when a payment is disputed or a provider changes its export format.

Controls for a 24/7 payment channel​

Instant settlement compresses the time available to catch an error, so controls should happen before release.

Use dual approval for high-risk payments​

Set thresholds by amount, counterparty risk, urgency, and destination-account changes. A payment outside business hours should not automatically bypass review. If your team is small, require owner approval for a defined class of transactions and review the resulting payment report the next business day.

Verify destination changes separately​

Do not approve a new bank account solely because a vendor sent an email or because the payment request contains a familiar logo. Use a known contact channel and retain the verification note. A fast payment can make an incorrect destination harder to recover.

Make retries safe​

Network timeouts are not proof that a payment failed. Before retrying, check the provider status and search for the original instruction ID. If your integration cannot guarantee idempotent retries, put the item in a pending state until its status is known.

Monitor limits and liquidity​

The Federal Reserve announced a 2025 increase in the FedNow transaction limit from $1 million to $10 million, but a participating institution may impose its own limits, controls, fees, or availability rules. Keep enough cleared liquidity for expected out-of-hours payments, and do not treat a higher network ceiling as a recommendation for your business.

Reconcile exceptions, not just totals​

Review rejected, timed-out, returned, duplicated, unmatched, and manually overridden items separately. A bank balance can agree with your ledger while one customer payment is applied to the wrong invoice and one vendor bill remains open.

Common implementation mistakes​

Posting when the button is clicked​

This makes cash appear to leave before settlement and leaves no clean answer when the instruction is rejected. Keep approval and submission evidence separate from settlement evidence.

Treating an instant payment like a card transaction​

Card payments have authorization, capture, settlement, and dispute conventions that do not map perfectly to account-to-account instant payments. Confirm the provider’s return and exception flow instead of copying a card clearing model without checking.

Discarding structured data after matching​

If the system uses remittance information to match an invoice but stores only the amount in the general ledger, the most useful audit evidence is gone. Retain the source reference and the normalized field.

Netting fees into the payment amount​

A $2,500 supplier payment and a $1.25 provider fee are different economic events. Record the fee separately unless your reporting and materiality policy clearly supports another treatment. Separate fees make provider pricing and payment-cost trends visible.

Assuming “real time” means “real time in the books”​

Your bank feed, accounting API, and reconciliation schedule may still be delayed. Document the expected lag and create an aged unmatched report so reviewers know whether a three-hour difference is normal or a problem.

A 30-day rollout plan​

Start with one low-complexity use case rather than switching every payment rail at once.

Days 1–7: map the flow. Pick one account, provider, and payment type. Write down each status, identifier, report, and expected timing. Confirm fees, limits, return procedures, and the fields available in exports.

Days 8–14: define accounting rules. Decide when payables and receivables are recognized, when cash is considered settled, whether a clearing account is needed, how fees are posted, and who owns exceptions. Use test transactions where the provider allows them.

Days 15–21: test failure paths. Exercise a duplicate retry, a rejected destination, missing remittance data, a return, and an out-of-hours settlement. A workflow that works only for a clean success is not ready for production.

Days 22–30: measure and review. Track match rate, average time to clear, aged clearing balances, return rate, manual overrides, and payment fees. Review the first month with both the person who approves payments and the person who maintains the books.

Keep the ledger ahead of the payment speed​

Instant payments can improve supplier relationships, customer access to funds, and cash timing. They can also expose weak references, unclear approval rules, and stale reconciliation habits within minutes instead of days.

The durable solution is a transparent event trail: approve the obligation, capture the instruction, verify the status, record settlement, separate the fee, and resolve every return. When your bookkeeping preserves those links, faster settlement becomes a useful operating capability rather than an unexplained change in the bank balance.

Simplify Your Financial Management​

As payment channels become faster, maintaining a clear record of every approval, settlement, fee, and exception becomes more important. Beancount.io offers plain-text accounting that is transparent, version-controlled, and AI-ready, giving you financial records you can inspect and reconcile without vendor lock-in.