The invoice you finalised is not the document that posts — 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 raises invoices or purchase bills in a currency other than the company’s own, and has gone looking for the journal behind one. In about twelve minutes you will know why it was not where you expected, and which document to look at instead.
Step 1 — Meet the document you did not create
After this step you will know that a foreign-currency document has a twin. GadgetSphere buys a container of accessories from a Singapore distributor and the bill is in US dollars. The moment somebody presses Finalise, BigLedger makes a second, complete copy of that bill with every amount converted into ringgit, and links the two together. The copy has the same lines, the same customer, the same dates and no document number of its own. Nothing on the screen announces it. From that point on there are two documents in the database where you believe there is one, and almost every question people ask about foreign currency is really a question about which of the two they are looking at.
Reference: Forex Applet
Step 2 — Learn which of the two actually posts
After this step you will stop looking in the wrong place. The foreign-currency document is saved and left alone: no journal, no stock movement, no cash book line, no loyalty points. The twin is the one handed to the job chain, so everything the fan-out does, it does in ringgit, from the copy. The backend states this three separate times by refusing outright to post a journal for a foreign-currency document, with an error that says exactly that. So when the accounts team asks why last month’s dollar invoice has no journal against it, the honest answer is that it never will have one — its twin does.
Reference: How Work Actually Runs
Step 3 — Understand why it was built this way
After this step it will look like a decision rather than an accident. A ledger is kept in one currency. If foreign documents posted directly, every report, every trial balance and every costing calculation would have to know how to convert, at some rate, at some date, every time it read a row. Converting once, at the moment of Finalise, into a real document that behaves like every other document, means the whole rest of the platform never has to think about currency again. The price is that there are now two documents, and the platform is not always careful to tell you which one you are being shown.
Step 4 — Read the twin column by column
After this step you will recognise a twin on sight. Every line amount, unit price, discount and tax figure is the original divided by the stored exchange rate. The currency label is changed to your company’s. Every posting flag is wiped clean, so the twin starts its life unposted and then posts everything. And one figure is copied straight across without being converted: the settlement balance, the number the aging reports read. So a twin carries a ringgit-labelled document whose outstanding balance is still the dollar figure. That is deliberate in the sense that nothing recalculates it, and it is worth knowing before you compare two totals and conclude one of them is wrong.
Step 5 — Know which screen shows you which
After this step you will stop seeing the same invoice twice and worrying. The aging reports, the outstanding-document reports, the sales and purchase reports and the monthly aging snapshot all exclude twins deliberately, by name, so what you see there is the document you raised, in the currency you raised it in. The Contra tab on a receipt voucher does not: it asks for finalised documents for this customer with a balance outstanding and filters on nothing else, so the original and its twin both appear. The twin is the one with no document number. Knock off the one with the number.
Reference: I knocked it off and the outstanding balance hasn’t changed
Step 6 — Check whether your twin was ever built
After this step you will be able to settle the commonest version of this complaint yourself. Open a finalised foreign-currency document and look at its exchange rate. If it is empty or zero, no twin was built, because BigLedger only treats a document as foreign when both currencies and a non-zero rate are present — and with no twin there is no journal, no stock movement and nothing to reverse later. Across all ninety of BigLedger’s tenant databases, roughly half of every finalised foreign-currency document has no twin. Then use Trace Document on the Financial Report applet, which will tell you which postings are missing rather than leaving you to guess.
Reference: Financial Report
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
- A base-currency twin BigLedger builds at Finalise and hands to the job chain — Forex Applet — Lifecycle and effects
- The picker asks only for finalised documents with a balance, so the original and its twin both appear; the twin is the one with no document number — What a Void Undoes — And one document class where the void lands somewhere else entirely
- The original document's balance, in the foreign currency, because twins are excluded from those reports by name — What a Void Undoes — And one document class where the void lands somewhere else entirely
- The exchange rate on the document — with no rate there is no twin, and with no twin there is nothing to post — Forex Applet — Lifecycle and effects
Next: Which rate, whose date, and which way round it is stored · Back to the series · Play this as a presentation