How hedging and risk transactions are set up in finance and ERP systems

Hedging normally lives in a treasury system that holds exposures, trades and valuations, with the ERP general ledger receiving summarised accounting entries. Policy and limits sit in documents outside both. Interfaces, mappings and reconciliations join the pieces, and more of that joining is done by hand than most diagrams admit.

Where the strategy is recorded

The hedging strategy is almost never a system object. It is a board or committee approved policy that names the risks to be managed, the instruments allowed, the counterparties permitted and the hedge ratios targeted. Treasury then translates parts of it into configuration. Counterparty limits, instrument types and approval levels get set up as static data in the treasury platform.

The gap between the written policy and the configured limits is where problems start. A policy change approved in a meeting may never reach the limit tables. Check that someone owns that translation.

How exposures reach treasury

Foreign exchange exposure comes mostly from the ERP. Open payables and receivables in foreign currency, purchase orders and sales forecasts are extracted and sent to the treasury system, sometimes through a direct interface and often through a spreadsheet upload. Forecast exposures usually arrive from business units in a template, and their quality varies widely.

Interest rate exposure is simpler to source. Debt facilities, intercompany loans and deposits are held as deals in the treasury system itself, so the floating rate profile can be read straight from there.

Balance sheet exposure, such as net investment in foreign subsidiaries, tends to be pulled from consolidation data at period end. It moves slowly and is often reviewed separately from transactional risk.

Trade capture and execution

Dealers execute on a trading platform or by phone with a bank. The deal is then captured in the treasury system, ideally by automatic feed from the platform. A different person from the dealer should confirm the trade against the bank's confirmation. That segregation is the main control in this whole area, and it is worth checking it still holds when people are on leave.

Settlement instructions flow from treasury to the payment system or bank portal. On settlement date the cash movement is matched back to the deal.

Valuation and hedge accounting

At each reporting date the treasury system revalues open derivatives using market data loaded from a provider. For designated hedges it also runs effectiveness testing and splits the fair value change between the effective portion, which goes to equity, and the ineffective portion, which goes to profit or loss.

Designation is the step most often done outside the system. Hedge documentation linking each derivative to a hedged item is frequently kept in a shared folder. If the system and the folder disagree, the auditors will find it.

Treasury platforms produce accounting events: deal booking, revaluation, accrual, reclassification on maturity and settlement. Each event is mapped to general ledger accounts through posting rules that the systems team maintains.

Getting entries into the ledger

The accounting events are summarised and posted to the ERP through an interface file or a journal upload. Some organisations post at deal level; most post summary journals by entity, currency and account. Manual journals still appear for corrections, for hedges designated late and for anything the posting rules do not cover. Those manual entries should be routed for approval like any other journal.

Reconciliation compares the treasury subledger to the general ledger balances for derivative assets, derivative liabilities, the hedging reserve and the related profit or loss lines. Each balance in the ledger should trace back to deals in treasury, and each deal should trace back to a confirmation. Differences usually come from failed interface runs, mapping changes that were not tested, or entries posted directly in the ERP.

Reporting draws on both systems. Risk reports showing exposure against hedge cover come from treasury. Disclosure notes for financial statements combine treasury data with ledger balances, and are often assembled in spreadsheets each quarter.

Questions to ask the people who run the process

What documented procedures describe and what people actually do often part ways here. Ask about the actual practice.

• Where do forecast exposures really come from, and who chases business units when the template is late or wrong?
• When the policy changed last, how did the new limits get into the system, and who checked them?
• Who confirms trades when the usual person is away?
• Which hedges are documented in the system, and which only exist in a folder or an email?
• How often does the interface to the ledger fail, and what is the workaround when it does?
• Which manual journals are posted every period, and why has nobody automated them?
• Where does market data for valuations come from, and who checks it before the month end run?
• What spreadsheet sits between the systems that would cause trouble if its owner left?
• How are breaches of limits reported, and has anyone ever been told to wait before reporting one?

The answers usually show that the core trade flow is well controlled and that the risk sits at the edges. Forecasts, designation records and manual postings are where a change to this process tends to deliver the most.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.