Trade Confirmations & Settlements Explained

Executive summary

Trading only creates realised value when trades are confirmed, settled, and paid. Confirmation and settlement, the back-office processes that turn an executed trade into cash and completed delivery, are where trading meets money, and where errors have direct financial consequences. Yet they are often the least glamorous and most under-invested part of a trading operation, which is exactly why they are a frequent source of losses, disputes, and delayed closes.

Getting confirmation and settlement right is fundamentally a data problem. When the settled trade is derived from the same authoritative record that was traded and risk-managed, settlement ties out cleanly; when it is re-keyed from a separate system, discrepancies and disputes proliferate. A modern ETRM treats settlement not as a downstream silo but as a governed derivation of the canonical trade.

This article covers why settlements matter, the trade confirmation process, the settlement lifecycle, physical versus financial settlements, invoice and payment management, accounting and ERP integration, and reconciliation and exception management. It builds on the three-office structure and connects to ERP integration.

Why settlements matter

Settlements matter because they are where trading value is realised or lost. A profitable trade that is mis-settled, invoiced wrongly, paid late, or disputed, can give back its profit in cost and effort, and systematic settlement errors erode margin quietly across the whole book. Settlement is the final, decisive step that converts a trading result into cash.

Settlements also carry operational and relationship weight. Late or wrong settlements damage counterparty relationships and can breach contractual terms; settlement disputes consume time and goodwill; and inaccurate settlement feeds inaccurate accounting. Because so much depends on getting it right, and because the volume of settlements is high, settlement accuracy and efficiency are a genuine source of value, not a back-office afterthought. The firms that settle cleanly protect the margin their trading earns, while those that do not leak it in errors, disputes, and reconciliation.

The trade confirmation process

Before a trade is settled, it must be confirmed: both parties agree that they have the same understanding of the trade’s terms. Confirmation is the first back-office step, and it catches discrepancies early, before they become settlement disputes.

The confirmation process matches the firm’s record of a trade against the counterparty’s, and flags any differences in price, volume, delivery, or terms for resolution. Getting this right early is valuable because a discrepancy caught at confirmation is cheap to fix, while the same discrepancy discovered at settlement is a dispute. A modern platform supports confirmation by working from the governed trade record and managing the matching and exception process against it, so confirmation is efficient and discrepancies are resolved before they propagate. Clean confirmation is the foundation of clean settlement.

The settlement lifecycle

Settlement follows a lifecycle from confirmed trade to reconciled payment, and a modern platform manages each stage on the governed record.

The defining requirement across the lifecycle is that each stage derives from the same authoritative trade and its actual delivery, so the settlement amount, the invoice, and the accounting entry are all consistent with the trade. When settlement is a governed derivation of the canonical trade, the numbers tie out at every stage; when it is re-keyed or reconstructed, discrepancies creep in and reconciliation becomes a permanent burden. This is why settlement quality is really data-architecture quality.

Physical versus financial settlements

Energy trading involves both financial and physical settlements, and they differ in what is settled. A financial settlement exchanges cash based on price differences (a swap settling against an index, for example); a physical settlement involves the delivery of the commodity and payment for the delivered quantity.

Physical settlement adds complexity because it depends on actual delivery: the settled amount reflects the measured quantity delivered, which may differ from the contracted quantity, and it must reconcile with operational records of the delivery. This ties settlement to scheduling and operations: the physical settlement depends on what was actually delivered, so it must derive from the operational record as well as the trade. A platform that holds trades, operations, and settlement on one canonical model can settle physical trades on actual delivery cleanly, because the delivery data and the trade data are already consistent, which fragmented systems cannot guarantee.

Invoice and payment management

Settlement produces invoices and payments, and managing these accurately is central to the process. An invoice must reflect the correct settlement amount, based on the right terms, prices, and delivered quantities, and payments must be made or received, matched, and tracked.

The value of accuracy here is direct: a wrong invoice is a dispute or a loss, and the volume of invoices means small error rates have large cumulative effects. A modern platform generates invoices from the governed settlement determination, so the invoice ties to the trade and its delivery, and manages payments and their matching against the same record. Because the invoice derives from the authoritative trade and delivery, it is right by construction rather than reconstructed and error-prone, which is what makes high-volume invoicing accurate rather than a persistent source of disputes and give-backs.

Accounting and ERP integration

Settlement feeds accounting: the settled trade must become an accounting entry in the finance and ERP systems. This is the point where settlement connects to the enterprise, and where clean derivation from the trade pays off in a clean close.

Good accounting integration derives the accounting entries from the same governed settlement and trade record, so the numbers in finance are consistent with, and traceable to, the trades they represent. This is the settlement side of ERP integration: the settled trade flows into finance through a clean, governed integration, with lineage from the ledger back to the trade. When accounting derives from the same authoritative record as trading and settlement, the month-end close ties out rather than requiring reconciliation between systems that disagree, which is one of the clearest operational benefits of a unified platform.

Reconciliation and exception management

No settlement operation is perfect, so reconciliation and exception management are core capabilities. Reconciliation matches the firm’s settlement records against counterparties, payments, and delivery records; exceptions, discrepancies, disputes, failed payments, must be tracked and resolved.

A mature approach treats exceptions as a managed queue: each discrepancy is captured, investigated, resolved, and recorded, with the whole cycle auditable. The volume and financial materiality of settlement make this essential, unresolved settlement exceptions are unrealised losses and unhappy counterparties. A platform that surfaces exceptions against the governed record, and manages them to resolution with an audit trail, keeps settlement clean and defensible. And because settlement derives from the canonical trade, many discrepancies that plague fragmented systems, where trading and settlement disagree, simply do not arise, which is the best kind of exception management: preventing exceptions rather than resolving them.

Settlement architecture

Bringing the threads together, a sound settlement architecture derives settlement from the canonical trade and operations model, through invoicing and payment to finance, with reconciliation and audit throughout. (This is a representative architecture, not a prescriptive standard.)

Because settlement derives from one authoritative model of the trade and its delivery, the settlement amount, invoice, payment, and accounting entry are consistent and traceable, so settlement ties out and the close is clean. This is the architectural difference between settlement as a governed derivation of trading and settlement as a disconnected silo perpetually reconciling against the trades it is meant to settle.

Why the Gravitas settlement platform is different

Gravitas derives settlement from the canonical trade and operations model.

Because settlement is a governed derivation of the canonical trade, it ties out at every stage and the close is clean, which protects the margin trading earns. And it is delivered at economics that suit desks the incumbents priced out. See the platform, who Gravitas is for, or request a demo.

Best practices

Getting confirmation and settlement right rests on a few principles. Confirm trades early against the governed record so discrepancies are caught before they become disputes. Derive the settlement amount, invoice, and accounting entry from the same authoritative trade and its actual delivery so they tie out. Settle physical trades on measured delivery, using operations data on the same model. Feed accounting from the governed settlement so the close ties out. And manage reconciliation and exceptions as a tracked, auditable queue.

The through-line is that settlement quality is data-architecture quality. When settlement derives from the canonical trade, it ties out by construction and protects the margin trading earns; when it is re-keyed from a separate system, it leaks value in errors, disputes, and reconciliation. Settlement is where trading value is realised, and a governed, unified platform is what makes that realisation clean.

Settlement KPIs

A settlement operation can be measured across accuracy, timeliness, and cleanliness.

Settlement and invoice accuracy measure whether value is protected; confirmation and payment timeliness measure operational health; reconciliation breaks and finance tie-out measure cleanliness. Together they describe a settlement operation that realises trading value rather than leaking it.