Malaysian exporters and importers routinely transact in more than one currency, and SCSB is rarely asked whether Dynamics 365 Business Central supports that — it does. The useful question is which decisions have to be settled before configuration, because several of them are difficult or expensive to unwind once transactions have been posted. The ones that cause trouble later are not the obvious ones.
Separate the three currency roles
Business Central distinguishes the currency a transaction is denominated in, the currency the general ledger is maintained in, and an optional second currency used for reporting. Conflating these is the most common source of later reconciliation difficulty, so it is worth being pedantic at the outset.
- Local currency (LCY) — the currency the general ledger is maintained in. For most Malaysian entities, MYR.
- Transaction currency — the currency in which a specific sale, purchase or bank account is denominated. A customer invoiced in USD and a supplier paid in SGD are both handled here, and this covers the large majority of ordinary import and export activity.
- Additional reporting currency (ACY) — optional. Where one is designated, Microsoft documents that Business Central automatically records amounts in both LCY and ACY on each general ledger entry and on other entries such as tax entries.
Trading in foreign currencies requires only the second of these. The third is a separate, heavier decision that many organisations enable without needing to, which is why it gets the next two sections.
What an additional reporting currency is not
Microsoft attaches an explicit warning to the feature, and one part of it matters particularly for Malaysian groups with overseas subsidiaries. Its guidance on setting up additional currencies states that the ACY cannot translate foreign subsidiary financial statements as part of a company consolidation, and that it can only be used to prepare reports in another currency as if that currency were the company's LCY.
Microsoft goes further and gives a worked limitation that deserves to be read carefully by anyone considering the feature. If a company holds a large receivables balance in a given currency and sets its ACY to that same currency, the receivables in that currency are not adjusted for exchange gains and losses in the ACY — only amounts in other currencies are. Microsoft states that reporting financial statements from the ACY in that situation might result in understated or overstated outstanding receivable balances.
SCSB draws a firm line from this. An ACY is a reporting convenience, not a translation or consolidation mechanism. Consolidation and translation for financial reporting purposes are governed by the applicable reporting framework and remain accounting judgements for the organisation and its accountants and auditors. An implementation should not be scoped as though enabling an ACY discharges them.
Activating an additional reporting currency rewrites existing entries
This is the point at which the decision stops being reversible in any comfortable sense, and it is the one most often discovered too late.
Microsoft documents that when the ACY is activated on the General Ledger Setup page, the Adjust Add. Reporting Currency batch job opens and converts LCY amounts on existing ledger entries into the ACY, using a default exchange rate taken from the rate valid on the work date. Residual amounts arising on that conversion are posted to residual gains and losses accounts, and after those are posted the batch job posts a rounding entry on the closing date of each closed year to the retained earnings account, so that income accounts end each closed year at zero in both currencies.
Once it has run, Microsoft lists the entry types that carry amounts in both currencies — general ledger entries, item application entries, tax entries, project ledger entries, value entries, production order lines and production order ledger entries — and all future entries of those types do the same. Microsoft also advises running the batch job outside working hours where a company has a large number of ledger entries.
SCSB's position is that this belongs in a sandbox with a copy of production data before it is done anywhere else, and that the work date used is itself a decision requiring an owner, not a default to be accepted.
The document rate and the adjustment rate are different fields
Here is a distinction that quietly produces wrong figures in otherwise well-run systems. On the Currency Exchange Rates page, Microsoft documents Exchange Rate Amount and Relational Exch. Rate Amount, which supply the default rate applied to new receivables and payables documents according to the working date. Separately, it documents Adjustment Exch. Rate Amount and Relational Adjmt Exch. Rate Amt, which are the rates used by the Adjust Exchange Rates batch job.
Microsoft states directly that before the batch job can be used, the adjustment exchange rates must be entered on that page. A team that diligently maintains the document rate and never populates the adjustment rate will find period-end adjustment does not behave as expected — and the symptom appears in the reported balance, not in an error message.
Microsoft also notes that an external currency exchange rate service can keep rates up to date, and adds the caveat that the service does not adjust exchange rates on already posted transactions; the adjustment batch job is what updates posted entries. Automating the rate feed therefore reduces the manual work but does not remove the period-end control.
Choose the adjustment method deliberately, and know where gains and losses land
Where an ACY is in use, Microsoft documents an Exchange Rate Adjustment field on each G/L account card with three options: No Adjustment (the default, appropriate where the LCY-to-ACY rate is always fixed), Adjust Amount (the LCY amount is adjusted, with gains or losses posted to the Realized G/L Gains Account and Realized G/L Losses Account specified on the Currencies page), and Adjust Additional-Currency Amount (the ACY amount is adjusted instead).
A separate setting governs tax entries. Microsoft documents this as the VAT Exchange Rate Adjustment field on the General Ledger Setup page, offering the same three options but applying them to tax entries. It is easy to configure the general ledger accounts carefully and never open this one. Note also that Business Central's tax terminology and behaviour vary by localisation, so confirm how the field presents in your own environment rather than assuming the documentation's label.
Where gains and losses land under the ordinary Adjust Exchange Rates batch job is worth stating precisely, because it is not uniform. Microsoft documents that for customer and vendor accounts the batch job posts to the accounts specified in the Unrealized Gains Acc. and Unrealized Losses Acc. fields on the Currencies page, while for bank accounts it posts to the Realized Gains Acc. and Realized Losses Acc. fields. Microsoft's own worked example follows an unpaid foreign-currency invoice through a period-end adjustment that raises an unrealised gain, then a reversal of that adjustment on payment, then the realised result at the actual payment rate. Confirming the mapping of all four accounts against the organisation's approved treatment is a short task that prevents a long reconciliation.
Controls to settle before the first posting
- Rate source and frequency. Where do rates come from, who updates them, how often, and who reviews the update? A stale rate table produces confidently wrong figures rather than obvious errors.
- Both rate fields. Confirm that document rates and adjustment rates are both maintained, and by whom.
- Gain and loss accounts. Confirm which accounts receive unrealised and realised differences, and residual differences, and that each matches approved policy.
- Rounding. Microsoft notes residual amounts can occur when Business Central rounds debit and credit amounts converted from LCY to an ACY. Agree which account absorbs them before they accumulate.
- Cut-off. Which rate applies at period end, and how are entries posted before that day's rate was entered brought into line?
- Access. Restrict who may add currencies, amend rates and run the adjustment job. Rate maintenance is a financially significant permission and is frequently granted too widely.
Test the cases that expose the configuration
Representative transactions rarely reveal a currency misconfiguration, because the representative case is the one that works. Test the awkward ones: a foreign-currency invoice partially settled across two periods at different rates; a credit note raised in a different period from the original invoice; a bank charge in a third currency; a payment that over- or under-settles; a rate entered retrospectively; and the period-end adjustment run twice.
Microsoft documents a Preview Posting action on the exchange rates adjustment report request page, which shows the effect of an adjustment before it is posted, either in detail by entry or summarised by currency. Use it during testing rather than posting and reversing. Where a mistake does need correcting, Microsoft notes that reversing a payment which had exchange rate adjustments posts reversal entries for those adjustments, and that the adjustment may need to be run again to reach the correct balance.
For each case, compare the posted result to the expected accounting outcome, reconcile to source records, and confirm tax entries behaved as intended.
Many organisations do not need an additional reporting currency
SCSB says this plainly because the feature is often enabled on the strength of the word "reporting" alone. An organisation that invoices in several currencies but reports in MYR, and whose overseas parent or lender simply wants figures converted for information, generally needs correct currency codes, disciplined rate maintenance and a reliable period-end adjustment — not an ACY. The conversion can be done outside the system with less risk and no irreversible change to posted entries.
An ACY earns its place where routine, repeated reporting in a second currency is needed directly from the general ledger, and where the organisation understands the limitation set out above. Where that is not the case, the simpler configuration is the better one, and SCSB would rather scope the smaller piece of work accurately.
Where implementation support fits
Where an organisation has defined its currency requirements and its approved treatment, SCSB's Business Central implementation service can be discussed. Accounting policy, presentation currency, consolidation and the treatment of exchange differences under the applicable reporting framework remain the responsibility of the organisation and its accountants and auditors.
This article is general information about Business Central configuration. It is not accounting, tax or regulatory advice, and it does not determine the treatment of foreign currency transactions for any organisation. Microsoft's product documentation changes over time; confirm the current position against Microsoft's own published material.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.