Where the exchange difference lands when you knock the invoice off — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This presentation is for whoever has to explain a gain or loss line nobody remembers posting. In about thirteen minutes you will know when BigLedger recognises an exchange difference, what it does with it, and the two ways it can fail to appear.
Step 1 — Fix the moment it happens
After this step you will stop looking for it at month end. BigLedger recognises an exchange difference at exactly one moment: when you knock a foreign-currency document off against a payment. Not when the rate moves, not when the month closes, not when a report is run. There is no revaluation run in the product at all — nothing sweeps your open dollar balances on the last day of the month and posts an unrealised gain. If your accounting policy needs one, it is a manual journal somebody writes, and it is not something a setting will switch on. What BigLedger gives you is the realised difference, on the day the money is applied.
Reference: I knocked it off and the outstanding balance hasn’t changed
Step 2 — Watch it happen inside the same request
After this step you will know why it is on screen so fast. When you tick invoices on a receipt voucher’s Contra tab and save, the applet sends a second request carrying the rows you ticked. The backend writes the mirrored contra pair, refreshes both documents’ balances, and then — still inside that same request, before the response comes back — checks whether either document is in a foreign currency and posts the difference. So the gain or loss is in the ledger before the screen has finished refreshing. That is unlike almost everything else in the platform, where posting is a background job you wait a moment for.
Reference: I knocked it off and the outstanding balance hasn’t changed
Step 3 — Do the arithmetic yourself
After this step you will be able to check the figure by hand. Take the amount you settled. Value it twice: once at the invoice’s own stored rate, once at the rate on the document that settled it. The difference between those two ringgit figures is the entry. That is all it is. Two consequences follow. If both documents carry the same rate the difference is zero and no journal is written at all, which is why most settlements produce nothing. And the rate used is whatever was stored on each document at the time, so a rate somebody typed in a hurry three months ago is still the rate this calculation uses today.
Step 4 — Name the two accounts and the direction
After this step you will know where to look in the chart of accounts. The difference goes to your company’s default Forex Gain account when it is a gain and the default Forex Loss account when it is a loss — these are company-level defaults, set once alongside the other default codes, not per document and not per currency. The balancing line goes to that customer’s or supplier’s own control account, chosen from whether the entity is set up as a receivable or a payable. A gain credits the gain account and debits the control account; a loss does the reverse. Two lines, nothing else.
Reference: Chart of Accounts Setup Guide
Step 5 — Find the journal, and read its date
After this step you will be able to locate one. The journal carries the document’s transaction date, not the date you did the settlement — so a February invoice settled in April produces a February journal, dated into a month you may already have signed off. Its posting date is the moment it was written, which is how you tell the two apart. And it is recognisable only by the contra it belongs to: no screen produced it, nothing on the receipt voucher mentions it, and its description is copied from the document’s own remarks. Search the ledger by date and amount, not by anything a person typed.
Step 6 — Know the two ways it does not appear
After this step you will recognise both failures. The first is loud: if your company has no default Forex Gain or Forex Loss account, the lines are dropped one at a time, nothing is left to post, and the settlement request fails with a message saying no journal was created. Set the defaults up before the first foreign settlement, not after. The second is quiet, and runs the other way: there is a second writer, a background processor on the twin’s own Finalise chain, configured on only four of BigLedger’s ninety tenants — and in the estate there are slightly more of these journals than there are settlements carrying them, which means a few have been written twice. If a gain looks doubled, count the journals against the contra before you adjust anything.
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- At the moment the invoice is knocked off, inside the same request that writes the settlement — I knocked it off and the outstanding balance hasn't changed — The one settlement that does post to the ledger
- The settled amount valued at the invoice's own stored rate, less the same amount valued at the settling document's rate — I knocked it off and the outstanding balance hasn't changed — The one settlement that does post to the ledger
- The document's own transaction date, with the posting date set to the moment it was written — I knocked it off and the outstanding balance hasn't changed — The one settlement that does post to the ledger
- The lines are dropped, nothing is left to post, and the request fails saying no journal was created — I knocked it off and the outstanding balance hasn't changed — The one settlement that does post to the ledger
- No — there is no revaluation run anywhere in the product — I knocked it off and the outstanding balance hasn't changed — The one settlement that does post to the ledger
Next: Voiding a foreign-currency document, and reading the residue it leaves · Back to the series · Play this as a presentation