Cloud Financial Transaction Systems

Executive summary

A payroll run that pays an employee twice, a collections platform that posts a payment to the wrong account, or a billing system that cannot explain an invoice total are not availability incidents. They are correctness failures with legal, financial and reputational consequences. Money movement is an irreversible side effect of software, so a financial transaction system is judged first on whether every amount it moves is correct, authorized and explainable, and only then on speed and availability.

The reference architecture in this paper places a double-entry ledger with an append-only journal at the center, as the system of record. Around it sit a calculation engine with versioned rules, a workflow engine that runs periodic processes and approvals as resumable, idempotent steps, a payments component that issues each instruction exactly once in effect, and a control plane that reconciles, audits and reports. Platform services supply identity, keys, messaging, scheduling and observability, and elasticity, residency, resilience and exit are treated as architectural decisions rather than operational details.

• Make the ledger the system of record: balanced postings, an immutable journal, corrections by reversal and derived balances.
• Give every transaction an explicit state machine and every money-moving request an idempotency key.
• Separate calculation, authorization and settlement, and enforce segregation of duties inside the workflow engine rather than in policy documents.
• Use strong consistency where money changes hands and eventual consistency for views and analytics, decided per operation.
• Build reconciliation and evidence into the first release, so that every figure traces to an input, a rule version and an approval.

The closing sections set out the quality attributes to balance, the pitfalls that recur in practice and a staged path from foundations through a first product to scale.

What makes money movement different

A rolled-back database transaction costs nothing; a payment that has left the bank is a fact in the world that only another payment can correct.

Most software is judged by availability and speed; financial transaction systems are judged first by correctness and evidence. A briefly unavailable payroll system inconveniences its users. One that pays the wrong amount, pays twice or cannot show how an amount was derived creates liabilities, regulatory exposure and a lasting loss of trust. The architecture must make wrong money movement impossible where it can, and detectable and correctable where it cannot.

Three properties follow. Irreversibility: a disbursement accepted by a payment rail is a side effect outside the system's transaction boundary, so the system must decide carefully before it acts and never act twice. Traceability: every amount must be explainable from identified inputs, an identified rule version and an identified approval. Periodicity: pay runs, billing cycles, accruals and month-end close run on calendars alongside real-time requests, so the architecture must serve interactive operations and scheduled peaks at once.

Obligations that shape design

Regulatory and contractual obligations are architectural inputs, not paperwork added at the end. Internal control over financial reporting requires that figures entering the books are complete, accurate and authorized, and that changes to the systems producing them are controlled. Data protection law restricts how personal and bank account data is collected, kept and moved across borders. Consumer credit and collections regulation imposes duties of fair treatment, communication limits, dispute handling and record keeping that differ by country and by type of debt. Accepting cards brings the Payment Card Industry Data Security Standard (PCI DSS), and each payment scheme brings its own operating rules. This paper describes such obligations as principles; the specifics for any jurisdiction and product must be confirmed with counsel.

Running examples and scope

Payroll is periodic calculation followed by disbursement. Each pay period the system gathers time, salary and benefit inputs, computes gross pay, deductions and net pay under versioned rules, obtains approval, pays employees and third parties such as tax authorities and benefit providers, and produces payslips and filings. Its pressures are a hard calendar, work concentrated into a few days, and exact reproducibility of past calculations.

Debt management is account-based. Each account carries a balance, a repayment schedule, accruals of interest or fees where the product allows them, payments from several channels, and a collections workflow when payments are missed. Its pressures are long-lived state, many small inbound payments to allocate correctly, regulated customer contact, and disputes that replay an account's history. The same patterns serve commercial lenders, utilities, payroll providers and public-sector receivables alike.

The scope is systems that an organization builds or assembles on cloud platforms from its own services, managed services and third-party components. Choosing core banking or enterprise resource planning (ERP) products is out of scope, as are card acquiring and trading systems, although the same patterns apply to them.

A financial system may be allowed to be slow or briefly unavailable; it may never be allowed to be wrong without knowing it.

Architectural principles

Principles outlast technology choices. Each of the nine below carries a design implication, because a principle without implications is a slogan, and together they are the criteria against which the rest of this paper, and any design review of a money-movement system, should be tested.

State, duties and distribution

The first principles concern the shape of state. A ledger records movements as balanced entries instead of overwriting balances, so the history is the truth and the balance a derivation. An explicit state machine reduces a payment or a run to a few reviewable states, so duplicates and losses have nowhere to hide. And because networks and workers fail, every request that moves money must be safe to repeat, which requires a caller-supplied key stored with the first outcome. Consistency is then decided per operation: a posting or a release needs one strongly consistent write, while a statement view or a notification can lag by seconds without harm.

The remaining principles concern people and operations. A calculation engine can never pay, an approver can never change a figure, and a payments component releases only what has been approved. Segregation of duties and approval limits live inside the workflow engine, enforced on every instance rather than by procedure. Evidence by design makes the audit trail a by-product of the operation, so reproducing a result years later is a query rather than an investigation. Reconciliation belongs in the first release because a system that cannot prove its ledger matches the bank is not finished. Elasticity rewards capacity that follows the calendar, provided batch work is partitioned and the idle cost between peaks is measured.

The reference architecture

The reference architecture has six layers and a control plane that spans them, as the figure below shows. The layering is logical: a small product may deploy several layers in one service and a large one may split a layer across many, but responsibilities and the direction of dependency stay the same, from channels down to data and platform services, with the control plane observing them all.

Channels, APIs and orchestration

The channel layer holds what people and partner systems touch: self-service for employees and customers, back-office consoles for administrators and collections agents, and partner portals. It holds no business rules and no money. The API and integration layer exposes the system through a gateway that handles authentication, rate limiting and request logging, publishes partner-facing application programming interfaces (APIs) and webhooks, and runs the exchange with banks, which remains largely file-based.

The process orchestration layer runs long-lived processes, such as a pay run, a billing cycle, an approval chain or a collections case, as durable workflows. A workflow engine keeps each instance's state, retries failed steps, waits for human decisions and timers, and shows operators where every instance stands. It coordinates; it never calculates or posts.

Domain services, data and the control plane

The domain services hold the business logic, each owning its data. Parties and accounts manage employees, customers, counterparties and their accounts and schedules; the calculation engine computes amounts under versioned rules; the ledger records every movement of value; payments and disbursements turn approved amounts into rail instructions and track their fate; and documents and notifications produce payslips, statements, letters and messages within the communication limits that regulation imposes.

The data layer separates stores by purpose: transactional stores, a ledger store with the strongest durability and consistency guarantees in the system, an event log that carries changes to other components, an analytical store for reporting and an archive for records past their active life. Platform services are shared and mostly provider-managed: identity and access management, secrets and keys, observability, scheduling and messaging. The control plane is where the organization proves that the system behaves: policy enforcement, the audit trail, reconciliation and reporting.

Two dependency rules keep the layering honest. Money-moving writes flow one way, from orchestration through domain services to the ledger and payments, never from a channel or a report directly into a store. And the control plane reads everything but changes nothing: a reconciliation break is resolved by a new, authorized transaction in the domain services, not by a correction inside the control plane.

The ledger as system of record

Double-entry bookkeeping records every movement of value as debits and credits of equal total, so that value taken from one account always arrives in another. An unbalanced entry is therefore detectably wrong, and a balanced set of entries explains where every unit of value came from and went. The method was first set out in print by Luca Pacioli, who described the practice of Venetian merchants, and Martin Fowler's Analysis Patterns carries its account, entry, transaction and posting-rule concepts into software design.

Accounts, entries and posting

A ledger account is a named bucket of value: an employee's net pay payable, a debtor's principal, a bank clearing account. A journal entry is a set of at least two lines, each naming an account, a direction and an amount, whose debits and credits balance. Posting appends the entry to the journal and makes it visible in balances; all of its lines post or none do, and its header carries the context that makes the movement explainable.

Immutability, balances and dates

A posted entry is never edited or deleted. An error is corrected by a reversing entry that undoes the original, followed if necessary by a correct entry, each with its own reason and approval, so the journal shows the mistake, the correction and the people involved. Database permissions or append-only storage enforce immutability, so that the application is not the only guard, and write-once storage with periodic hashing makes tampering evident.

A balance is derived: the sum of an account's entries since it opened. Summing from the beginning does not scale, so the ledger keeps balance checkpoints at period boundaries; a nightly job that rebuilds them from the journal and compares the results is one of the cheapest controls in the system. Accounting periods are opened and closed, and an adjustment found after close posts into an open period with an effective date that says where it belongs.

The effective date says when an event belongs economically; the posting date says when the system recorded it. They differ whenever information arrives late: a payment received on the last day of the month but reported on the first, or a salary change notified after the pay run that should have included it. Keeping both is the foundation of retroactive adjustments in payroll and of interest recalculation in debt management.

Currency, general ledger and event sourcing

Amounts are stored as integers in the currency's minor unit, or as fixed-point decimals with a declared scale, never as binary floating-point numbers, which cannot represent most decimal fractions exactly. ISO 4217 defines each currency's code and its number of minor unit digits, which varies (two for the US dollar, none for the Japanese yen, three for the Kuwaiti dinar) and must be looked up rather than assumed. Rounding, and the allocation of remainders when an amount is split, belong to the versioned rule set, and a multi-currency ledger records each entry in transaction and reporting currency together with the exchange rate and its source.

The transaction system's ledger is a sub-ledger holding detail per employee, debtor or invoice; the finance system's general ledger (GL) needs summaries. On a schedule the sub-ledger posts summarized journals to the GL through a chart-of-accounts mapping and keeps the batch identifiers, so that any GL figure can be traced back to the entries behind it. The posting interface is itself idempotent and reconciled.

Event sourcing, deriving an entity's state by replaying the events that changed it, fits a ledger naturally because a journal already is an event log of value movements. Its cautions are practical: snapshots are needed for performance, event schemas must be versioned for the life of the data, replays of long histories are slow during incidents, and personal data inside immutable events complicates erasure. It suits the ledger and account history, rarely every service.

Workflows and calculation

Periodic processing is where financial systems most often fail: a pay run that stops halfway and cannot be restarted safely, a billing cycle that gives different results on a rerun, an approval given on numbers that changed afterward. The remedy is to model every periodic process as a workflow of resumable, idempotent steps with explicit approval gates, and to make calculation a pure, versioned function of its inputs.

Resumable steps and approvals

Each stage is a workflow step with a recorded outcome, written so that running it again after a crash produces the same result and no further side effects. Preparation freezes the inputs and the rule and rate versions into a run snapshot, so calculation reads the snapshot rather than live tables. Calculation writes results keyed by run and account, so a repeated partition overwrites identical results instead of duplicating them, and commit and disbursement use keys derived the same way.

Maker-checker approval requires that whoever prepared a run or payment cannot approve it, and approval limits route larger amounts, unusual variances or first-time payees to additional or more senior approvers. The workflow engine enforces both: it knows the maker, checks roles and limits before offering the task, and records the approver, the time and a hash of exactly what was approved. If anything changes afterward, the approval is void and the step reopens.

Calculation engines and adjustments

A calculation engine takes inputs and a rule set version and returns amounts with an explanation. Rules and rates are effective-dated: each version applies from a date, several coexist, and a calculation for a past period uses the version in force then. The engine is deterministic, so a preview run produces exactly what the committed run will, and a dispute years later is answered by rerunning the original inputs under the original version. Rules and rates are promoted between environments as versioned, reviewed artifacts, like code.

Retroactive changes, such as a backdated salary increase or a payment that should have reduced interest earlier, are handled by recalculating the affected periods under the rules then in force and posting the difference in the open period with the original effective date; the original entries stay. The same mechanism serves a waived fee or a reallocated payment in debt management.

Calendars, scale and exactly-once disbursement

Calendars and cut-offs are first-class configuration: business days per country and rail, cut-off times after which an instruction settles on the next business day, pay dates that move off holidays, and each rail's lead time. Every date is stored with its time zone. Calculation scales by partitioning by employee, account or client, with partitions sized so that a failed one can be rerun alone and results merge deterministically.

Disbursement must happen exactly once per approved amount. Strictly, no network can guarantee that a message is delivered exactly once; what the system can guarantee is that a repeat has no further effect. A payment instruction identifier is therefore generated at approval, stored in the ledger before the instruction is sent and carried in the instruction itself, so that a retry after a timeout sends the same identifier and is recognized as a repeat.

Payment rails and external parties

Everything up to disbursement happens inside the system's transaction boundary. Once an instruction is handed to a bank or a payment network, the system becomes one party in a conversation it does not control. Rail integration is therefore designed around messages, acknowledgments, rejections, returns and statements, each of which changes the state of a payment that the system must track.

Files, messages and transmission

Rails differ in format, rhythm and finality: high-value transfers through real-time gross settlement systems, batch schemes such as automated clearing houses, card networks, and instant payment schemes that settle in seconds. ISO 20022 defines a common business model and message definitions, most often exchanged as Extensible Markup Language (XML), organized into business areas such as payment initiation (pain), clearing and settlement (pacs) and cash management (camt). A customer credit transfer initiation (pain.001) and a bank-to-customer statement (camt.053) are typical of the messages a transaction system sends and receives.

In the United States, Automated Clearing House (ACH) entries travel in batches within files that settle on a schedule, under the Nacha Operating Rules. For euro payments, Single Euro Payments Area (SEPA) credit transfers and direct debits follow the European Payments Council's scheme rulebooks, across a payment area that extends well beyond the euro area itself. These are examples, not recommendations: the payments component isolates rail-specific formatting behind one internal instruction model, so that adding a rail or a country adds an adapter rather than a rewrite.

Transmission uses the bank's channel, commonly managed file transfer over an encrypted protocol with mutual authentication, or an API with signed requests. Files are signed, encrypted at rest, logged with their hashes and never generated by hand; credentials and certificates live in the key management service and rotate on a schedule.

A state machine per payment

Each instruction follows an explicit state machine, shown in the figure below, and every transition carries a timestamp and the message that caused it. A rejection happens before settlement, typically for a formatting or account validation failure, and arrives as a status report (in ISO 20022 terms, a pain.002 or pacs.002 message). A return happens after settlement, when the receiving bank sends the funds back with a reason code, such as an ACH return code or an ISO 20022 payment return (pacs.004). Both post ledger entries, and a status that does not arrive within its expected window raises an alert rather than being assumed.

Duplicates, statements and intervention

Duplicate prevention must be end to end. The instruction identifier created at approval is carried in the rail message, the ledger and the bank's acknowledgment, so a file resent after a transmission failure is recognized as a repeat on both sides, whatever duplicate detection the bank also offers. Bank statements and intraday reports are ingested daily or more often, parsed into a common model and matched against expected settlements, and every difference becomes a reconciliation break with an owner and an age.

A manual intervention queue holds payments still rejected, returned or unmatched after the automatic rules have run, with full context, the allowed actions, the role permitted to act and a record of what was done. Fixes happen through this queue and the domain services, never through a database console.

Other external parties

Payroll systems exchange data with tax authorities, pension and benefit providers and time-and-attendance systems; debt management systems with credit bureaus, payment service providers and legal partners. The interfaces vary by country and are described here generically: each is an adapter with its own format, calendar, acknowledgment and error handling behind the same internal model, logged and reconciled like a payment, and subject to the privacy obligations described in the next section.

Controls, audit and evidence

Controls are how a financial system proves, to its own management and to external auditors, that money moved only when it should have, by the amounts it should have, with the approvals required. Most controls in this architecture are automated and produced by the system as it works; the rest are periodic reviews made cheap by system-generated evidence.

The audit trail

Every change to financial state, and every decision about it, produces an audit event: who acted, in what role and from where; what changed, with values before and after; when, with a trusted timestamp; and why, with the reason code, the request and the approval behind it. Audit events are written in the same transaction as the change, so no change exists without its event, and they are kept apart from operational data in tamper-evident storage such as hashed append-only logs or write-once object storage.

Segregation, limits and change control

Segregation of duties and approval limits, introduced in the section on workflows and calculation as workflow mechanisms, are reviewed as controls by producing from the system who holds which roles, who approved what above which limit, and any case in which one identity was both maker and checker. Privileged production access, including to the database, is granted just in time, approved, time-boxed and recorded in the same audit trail.

Change control covers code, configuration, rules and rates alike. Section 404 of the Sarbanes-Oxley Act (SOX) requires the management of companies that report to the US Securities and Exchange Commission to assess their internal control over financial reporting (ICFR), and systems that feed the books are usually in scope. Similar expectations appear in other jurisdictions and in the processing integrity criteria that System and Organization Controls (SOC) 2 reports can cover. Every change is therefore traceable to an approved request, tested, reviewed by someone other than its author and deployed by an automated pipeline, through which rule and rate tables also travel so that they cannot drift between environments.

Reconciliation, retention and privacy

Reconciliation catches what preventive controls missed: the ledger against bank statements, the sub-ledger against the general ledger, calculated against disbursed totals, and expected against received files. Breaks are aged, owned and closed through authorized transactions, never by editing a record until the difference disappears. Evidence for auditors should be a report the system produces on demand, such as the full history of a payment, rather than a quarterly exercise in screenshots.

Retention and legal hold follow the records policy: financial records are kept for the periods that tax, employment and financial reporting law require, personal data no longer than its purpose needs, and both are held when litigation demands it. Privacy by design applies with particular force to bank account and identity data: collect the minimum, store bank details tokenized or encrypted at the field level, mask them by default and log every unmasked access. Where card payments are accepted, as is common in collections, PCI DSS applies, and the usual answer is to keep card data out of the system through a tokenizing payment service provider, which shrinks the scope of the assessment rather than removing it.

An auditor should be able to pick any amount the system has ever paid and reach, in minutes, the inputs, the rule version and the approval behind it.

Cloud platform choices

Public cloud changes how the architecture is realized rather than what it must do. The choices below recur in every money-movement system; each is a trade-off to decide and record, and the major providers' well-architected frameworks offer checklists for the generic parts of each decision.

Managed services and resilience

Managed relational databases, queues, object storage, key management and workflow or state-machine services remove undifferentiated operations and come with the provider's attestations, such as SOC 2 reports and ISO/IEC 27001 certification. Those attestations cover the platform, not the system built on it. The ledger store favors a managed relational database that offers serializable isolation for balance-affecting writes, synchronous replication across availability zones, point-in-time recovery and immutable backups. Self-management is justified only where a product or a regulator requires a degree of control the managed service lacks, and the justification is recorded.

Availability zones protect against the failure of a data center; regions protect against the failure of a provider region. The ledger favors active-passive deployment across regions. Active-active writes over asynchronous replication need conflict resolution, which a ledger cannot tolerate, and multi-region databases that avoid conflicts through consensus add cross-region latency to every posting; read models and channels, by contrast, can run active-active. The ledger's recovery point objective (RPO) should be close to zero, which synchronous replication within a region provides and cross-region replication may not, and its recovery time objective (RTO) must fit the calendar, since a missed pay day is a different failure from an hour of downtime on a quiet afternoon. Recovery is rehearsed, including a complete run on the recovered system.

Residency, keys and isolation

Data residency determines where personal and financial data may be stored and processed, under data protection law, sector rules and client contracts. It constrains region choice, replication targets and the location of staff with access, and it is recorded as an attribute of each data set and tenant and enforced by placement rules. Encryption in transit and at rest is the easy part; the decisions are about keys. Keys are held in the provider's key management service, backed by hardware security modules (HSMs), with customer-managed keys for the ledger, the audit trail and bank data, scheduled rotation, separation of key administration from data administration, and an audit log of every use. Workloads run in private networks with ingress only through the gateway and egress restricted to known bank and partner endpoints.

Tenancy, cost and exit

Products serving many clients choose a tenancy model: pooled, with tenants sharing infrastructure separated by a tenant key enforced in every query and event; siloed, with dedicated databases or accounts per tenant; or a mix in which the ledger and audit trail are siloed for large or regulated clients. The choice drives cost, blast radius, residency and the ease of exit for a single client, and it is expensive to change later. Elasticity pays for period-end peaks only when batch work is partitioned and compute is released afterward. The idle cost between peaks is the usual surprise, so cost per run and per tenant is measured from the first month.

Portability and exit are regulatory as well as commercial concerns. The EU Digital Operational Resilience Act (DORA) requires the financial entities in its scope to put exit strategies in place for information and communication technology (ICT) services that support critical or important functions, and supervisors elsewhere publish similar outsourcing expectations. Whether a given organization is in scope must be confirmed with counsel.

Quality attributes and trade-offs

Every architecture balances quality attributes, and in a financial transaction system the order of priority is unusual: correctness and auditability first, then availability during the windows that matter, then latency and throughput. Making the order explicit settles many design arguments before they start.

Consistency against latency

The central trade-off is between consistency and latency, decided per operation rather than per system. The matrix below places common operations by how strongly they need consistency and how quickly they need an answer. The emphasized quadrant is where a financial system differs from most others: operations that move money need both a strongly consistent decision and a prompt response, which argues for a small, well-indexed ledger transaction rather than a distributed one.

Daniel Abadi's PACELC formulation makes the same point for replicated data: even when no network partition is present, a distributed store trades latency against consistency, so the trade-off is present on every request, not only during failures. Pat Helland's argument, that systems beyond the reach of a single transaction must be built from independent entities exchanging idempotent messages, describes the boundary between the ledger and everything around it.

Where eventual consistency is acceptable it should be visible: a balance view that may lag shows its as-of time, a notification is sent only after the fact it announces has committed, and reports carry the cut-off at which they were produced. Where it is not acceptable, the operation stays inside one aggregate in one strongly consistent store, and the temptation to split the ledger across services for scale is resisted until partitioning by tenant or account has been exhausted. Martin Kleppmann's Designing Data-Intensive Applications is a standard reference for the mechanics of isolation levels and of exactly-once processing.

Recurring pitfalls

The failures of financial systems are repetitive, and most are the inverse of one of the principles above. They are listed with their remedies so that an architecture review can check for each.

A staged path

Building the whole architecture before the first product ships is as risky as building none of it. A staged path delivers a working product early while laying down the parts that are expensive to retrofit.

1. Foundations. A ledger service with journal, accounts, periods and checkpoints; identity, key management, audit trail and observability from the platform; a workflow engine; and a pipeline that promotes rules and rates as versioned artifacts.
2. First product. One product, such as a single-country payroll or a single debt portfolio, on one rail, with calculation, approval, disbursement, statement ingestion and reconciliation complete end to end, and the evidence reports an auditor would ask for.
3. Hardening. Recovery rehearsals including a full run on the recovered system, a second rail or country behind the same payment model, tenancy and residency rules enforced by the platform, and control reviews running from system-generated evidence.
4. Scale. Partitioned runs on elastic compute, cost per run and per tenant measured, further products sharing the ledger, workflow and control plane, and architecture decision records kept up to date as each trade-off is revisited.

Conclusion

A financial transaction system is a machine for making irreversible decisions carefully. The reference architecture in this paper places a double-entry, append-only ledger at the center as the system of record; surrounds it with a calculation engine whose rules are versioned, a workflow engine whose steps are resumable and whose approvals are enforced, and a payments component that issues every instruction exactly once in effect; and wraps a control plane around them that reconciles, audits and reports. Cloud platforms supply the identity, keys, durability, elasticity and managed services that make the design practical, and they add decisions about regions, residency, tenancy and exit that must be made deliberately.

None of this depends on a particular provider, product or rail. It depends on a few commitments made early: that money moves only through the ledger and the state machines, that every money-moving request is idempotent, that calculation, approval and settlement stay separate, that evidence is produced with every change, and that reconciliation is part of the definition of done. Organizations that make those commitments in the foundations stage find that payroll, debt management, billing and disbursements become variations on one architecture rather than four separate systems.

Glossary

Append-only journal

A ledger store to which entries can only be added, never edited or deleted, so that the full history of value movements is preserved.

Balance checkpoint

A stored balance at a period boundary, derived from the journal, that lets a current balance be computed without summing every entry since the account opened.

Control plane

The part of the architecture that enforces policy and proves behavior through the audit trail, reconciliation and reporting; it reads every layer and changes none.

Double-entry bookkeeping

A method that records each movement of value as debits and credits of equal total, so that the entries always balance.

Effective date

The date on which an economic event belongs for accounting purposes, as distinct from the posting date on which it was recorded.

Event sourcing

A persistence pattern in which the state of an entity is derived by replaying the sequence of events that changed it.

General ledger (GL)

The organization's primary set of accounts, maintained in the finance system, to which sub-ledgers post summarized journals.

Idempotency key

A caller-supplied identifier stored with the outcome of a request, so that a repeated request returns the original outcome instead of acting again.

Maker-checker

An approval arrangement in which the person who prepares a transaction cannot be the person who approves it; also called the four-eyes principle.

Minor unit

The smallest denomination of a currency, such as a cent; ISO 4217 specifies the number of minor unit digits for each currency.

Payment instruction identifier

A unique identifier created when an amount is approved and carried in the ledger, the rail message and the bank's acknowledgment to prevent duplicates.

Payment rail

A network or scheme through which funds move between institutions, such as an automated clearing house, a card network or an instant payment scheme.

Reconciliation break

A difference between two records that should agree, such as the ledger and a bank statement, which must be investigated and resolved.

Rejection

A payment refused before settlement, typically for a formatting or validation failure, as distinct from a return.

Return

A payment that settled and was later sent back by the receiving bank with a reason code, as distinct from a rejection, which happens before settlement.

Reversing entry

A journal entry that cancels the effect of an earlier entry, used to correct errors without editing the original.

Segregation of duties

The control principle that no single person may perform all the steps of a sensitive process, such as creating, approving and releasing a payment.

Sub-ledger

A detailed ledger for a specific area, such as payroll or receivables, whose totals are posted in summary to the general ledger.