How international transaction management is set up in finance and ERP systems

In most finance systems, each legal entity records its international transactions in its own ledger and functional currency, and it also keeps the original transaction currency. Intercompany flows carry a trading partner code. That code lets both sides be matched during the period and then removed when the group consolidates.

Where the transaction first lands

Very few cross-border transactions start in the general ledger. They begin in a subledger. A supplier invoice arrives in payables. A customer bill goes out through receivables. Intercompany service charges usually start in a dedicated billing module, and some groups still raise them from a spreadsheet upload. The subledger holds the detail, such as the document, the counterparty, the currency and the tax treatment. The ledger receives a summarised posting.

This split matters for anyone redesigning the process. A change at the source document level carries through to every downstream report. A change made only in the ledger leaves the subledgers telling a different story.

Currency handling

Every entity has a functional currency defined in its master data. Each transaction is stored in its document currency and translated at a rate pulled from a rate table. Treasury or a market feed usually maintains that table. The system books gains and losses on settlement automatically. It revalues open items at period end using the closing rate, and those entries normally reverse at the start of the next period.

Group reporting adds another layer. Consolidation translates each entity's results into the group currency. Balance sheet items use closing rates. Income statement items use average rates. Translation differences go to a reserve account. All of this depends on rate types being set up correctly, and an incorrect rate type is a common source of quiet errors.

Intercompany as its own flow

Mature setups treat intercompany activity as a separate process with its own controls. When one entity books a charge to another, the system can generate the mirror entry in the receiving entity. Where that automation is missing, the second side is keyed in by hand, often late and sometimes at a different rate.

Before close, each pair of entities reconciles its balances. Differences go into a suspense or clearing account while someone investigates. Timing, currency, and charges disputed by the receiving side explain most mismatches. The consolidation tool then eliminates the agreed balances, along with intercompany revenue and cost, so the group accounts show only external activity. Groups that run a netting cycle settle intercompany payables and receivables against each other, and only the net amount moves as cash.

Posting to the ledger and tying out subledgers

Subledgers post to control accounts. Users should not be able to post manual journals to those accounts, although many systems allow it unless someone switches the option off. Adjustments that cannot come from a subledger go through manual journals. Those journals need a preparer, a reviewer and supporting evidence attached.

At close, finance compares each control account balance to the open items in the matching subledger. A good reconciliation traces a ledger balance back to individual documents, and from those documents to the original invoice or contract. When the two sides disagree, the correction is booked in whichever side is wrong. A plug entry in the ledger only hides the problem.

Payments across borders

Foreign payments pass through the payables run like domestic ones, with extra steps. The system checks that the bank details are valid for the destination country and converts the amount when the paying account holds a different currency. It then produces a payment file in the format each bank requires. Payments that are approved but not yet due are held until their value date. Treasury often reviews large or unusual payments before they are released.

Questions to ask the people who run it

Written procedures often describe the system as it was designed. The team usually works around it in ways nobody has written down. These questions tend to bring the gaps out:

• Where do intercompany charges really originate, and who keys the receiving side?
• Which exchange rate do staff use when the system rate looks wrong, and where does it come from?
• What sits in the intercompany suspense account right now, and who owns clearing it?
• Are any manual journals posted to control accounts, and why?
• When the two sides of an intercompany balance disagree, who decides which one is right?
• Which reconciliations are done outside the system, and in what file?
• What happens to a foreign payment that the bank rejects?
• Which reports do people rebuild by hand before they trust them?

The answers to the last two often show where the real process lives.

Where setups usually drift

New entities get added without full intercompany mapping. Trading partner codes are left blank on manual journals, so eliminations miss those entries. Rate tables are updated late. Over time the suspense account turns into a permanent home for differences that nobody wants to chase.

None of these problems shows up in a process diagram. They appear in the close calendar, in the size of the elimination adjustments, and in how much time the team spends explaining variances before the group numbers can be signed off. Anyone planning a change should look there first and study the configuration second.

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.