Ask a treasury team why their FX hedging is still driven from spreadsheets and the answer is rarely that they like spreadsheets. It is that the exposure data lives in six places: AR and AP in the ERP, open purchase orders in procurement, intercompany loans in a separate register, forecasts in the planning tool, positions in the TMS, and local oddities in subsidiary ledgers. Someone has to pull all of it, normalise it, and reconcile the discrepancies before anyone can even say what the hedge requirement is. By the time that is done, the numbers are days old.
The vendors selling AI for treasury tend to lead with the decision layer: models that suggest when to hedge, how much, and at what tenor. That layer is real and useful, but it is the third step, not the first. The 2026 pattern among teams that have made this work is unglamorous and consistent: exposure data plumbing first, then decision support, then controlled execution, with hedge accounting automated last of all. AI sits on top of a disciplined exposure data model or it sits on top of noise.
The exposure register is the product
The foundational artefact is an exposure register: the master inventory of FX-sensitive items across all entities and source systems. It has to cover more than AP and AR. Transaction exposure, translation exposure, and economic exposure all belong in it, because visibility limited to booked payables and receivables systematically understates what the business is actually carrying.
Each entry needs a minimum data contract:
- Identification. Currency pair, legal entity, source document, and the source system it came from.
- Timing. Maturity or settlement date, and for forecast items, the forecast horizon and time bucket.
- Provenance. The owner responsible for the number, its update frequency, and a confidence level. Estimated values get flagged explicitly rather than blended into totals; a register that hides its soft spots produces hedges against exposures that never materialise.
- Hedgeability. Whether the item is eligible for designated hedge treatment under policy and accounting rules. Determining this in the workflow, before any recommendation, saves the later embarrassment of a proposed hedge the accounting team must unwind.
Automating capture is where the analyst hours go first. Direct ingestion from ERP, TMS, consolidation, and planning systems replaces re-keying, and it also removes the versioning problem where two analysts hedge from two different extracts. One practical discipline the practitioner literature keeps repeating: standardise the exchange-rate source across every system feeding the register, and run recurring shock tests. Inconsistent rate bases quietly distort both the exposure numbers and the hedge-ratio analysis built on them.
Netting before hedging
Gross operational flows are not the hedge requirement. The system’s second job is aggregation and netting: offset opposite-direction positions by currency, entity, and tenor bucket so treasury sees net exposure, the number a hedge should actually cover.
Intercompany balances deserve their own path. Left in the same pool as third-party flows, they inflate gross exposure and can distort the net picture; the standard treatment is to net them separately, often through multilateral netting, before consolidation. This is also where FX automation meets in-house banking: groups running an IHB have subsidiaries submit forecast revenues, payables, and receivables, and the centre aggregates and nets internally before going to market. Fewer external trades, tighter spreads, and one place where policy is enforced instead of twenty.
The forecast dimension is what turns this from reporting into risk management. Hedging only booked balances means hedging late. Including forecast flows converts uncertain operating activity into hedgeable exposure bands by tenor, so coverage can be laddered against expected timing rather than bolted on after invoices land. The cost is forecast uncertainty: the further out the flows, the harder it is to keep policy discipline without over-hedging. The mitigation is structural, not clever: lower target coverage ratios at longer tenors, layered hedging that tops up as forecasts firm into orders and invoices, and the confidence flags from the register carried all the way into the hedge decision.
Decision support inside policy rails
With a clean, netted, tenor-bucketed exposure view, the decision layer becomes tractable. The system compares net exposure against existing coverage and policy thresholds, computes the hedge gap per currency and bucket, and proposes trades: instrument type, tenor, notional, estimated cost, ranked by gap priority. Models can inform the timing and sizing within those rails, drawing on forecast data and historical hedge performance.
The rails are the point. Every recommendation is constrained by policy: approved instruments, counterparty limits, tenor limits, minimum and maximum coverage ratios. The tool is a supervised decision aid, and the useful test for any vendor demo is whether the system can show, for a given proposal, which exposure it covers, which policy rule triggered it, and how it maps to the intended accounting designation. If it cannot, you are buying a black box that your auditors will eventually ask you to explain.
Two failure modes need standing monitors rather than quarterly reviews. Coverage drift: exposures update continuously, hedges do not, and yesterday’s compliant coverage ratio can be today’s breach. Expiry risk: positions approaching maturity with the underlying exposure still open. Both are trivially automatable alerts and both, in manual regimes, are the classic sources of unpleasant surprises.
Execution, accounting, and the audit trail
Only after the exposure and decision layers are stable does execution automation earn its place. The approved recommendation routes to the trading venue or bank portal, confirmations match back automatically, and the derivative administration that follows, valuations, reporting, settlement tracking, stays attached to the same workflow rather than migrating into a side spreadsheet.
Hedge accounting comes last in the sequence because it is the most technically demanding step and inherits every upstream data problem. Automate it only after the register, netting, and designation logic have proven stable across a few reporting cycles.
The operational spine through all of it is auditability. For every hedge on the books, the system should reconstruct: the exposure snapshot it was raised against, the policy version in force, the rule that triggered the proposal, the approver, the execution details, and the accounting designation. That record is what makes the difference between automation a treasurer can defend to the audit committee and automation that gets switched off after its first awkward question. Reactive spreadsheet hedging does not fail because treasurers lack judgement; it fails because the data arrives too late and leaves no trace. Fix the data and the trace, and the judgement gets room to work.
FAQ
Where does hedge accounting fit in the automation sequence?
Last, deliberately. Hedge accounting depends on clean exposure data, stable designation logic, and a workflow that reliably links each hedge to the exposure it covers. Automating it before those exist locks in bad plumbing. The practical order is exposure consolidation first, then reporting and analytics, then execution, then hedge accounting once data quality and governance have held up for a few cycles.
How do you handle exposures the system can only estimate?
Flag them, do not blend them. An exposure register that mixes booked invoices with rough forecasts into one number gives treasury false precision at exactly the point decisions are made. Tag each item with its source system, owner, update frequency, and confidence level, and let the netting and hedge-gap views show estimated amounts separately, so the coverage decision on soft numbers is a conscious one.
Does automated hedging mean the system executes trades on its own?
Not in any setup we would defend. The system computes net exposure, compares it to policy thresholds and existing coverage, and proposes instrument, tenor, and notional with the policy rule that triggered the proposal. A human approves; execution and confirmation matching are then automated downstream of that approval. The audit trail must show who approved what, against which exposure snapshot, under which policy version.