Double-entry for multi-currency trading software, Ronald.

I'm puzzling over how you are advising our C++ writing visitor.

Suppose he has clients in Germany and the UK who buy 1m of USD Futures
in the US at 1 Euro equals 1 USD and 2 USD equal 1 GBP. Later they
sell them for 2m USD, and meanwhile the Euro is worth 4 dollars and 1
dollar buys four GBP.

Did they make a profit and what's the double entry?

 

We've discussed how to build a car, not how to drive it.

Well, let's see. Although clearly they will both have made a 100%
capital gain in dollar terms, overall the Germans will have made a
50% loss and the Brits a whopping 1500% gain in their own currencies.

I'll need to get back to you on that...

 

Exactly. I don't think you can. But as a data exercise it is trivial.
I don't know anything about futures, but if they are like shares:

Name
Transaction Quantity
Transaction Price USD
Transaction Price GBP
Transaction Price Euro...
....
....then at each significant anniversary...
....
Frozen Price USD
Frozen Price GBP
Frozen Price Euro...

....gives you everything you need to calculate any Profit or Loss for
any Quantity between any two Dates in any Currency.

I don't think our friends need learn bookkeeing at all

 

That season is but 6 months away but OH YES I CAN.
I just didn't have the time yesterday.

I presume that by "you" you don't actually mean me, but "one",
i.e. that it's a general impossibility. But that's rubbish.
Anything that happens in a real world trading situation is
capable of being modelled in accounting terms and kept track
of in books. It's just a question of how to do it.

One obvious requirement in a set of accounts which must balance
at all times is that the various accounts within it can't be
denominated in different currencies which are free to fluctuate
with respect to each other, because the books wouldn't stay balanced.
Therefore the accounts need to be kept in a single "home currency"
but in addition you need to track, in the case of "foreign" accounts,
what the foreign balances are which are being shadowed by the "home
currency", and therefore what the last exchange rate was at which
those accounts were valued.

You have to recognise that fluctuations do give rise to real gains
or losses, and these needs to be accounted for properly whenever
the accounts are revalued to the latest exchange rate. One can do
these revaluations periodically (if you want an update), or just
when strictly necessary, which is on the occasion that any event
occurs which affects the balance of that account.

Doing this isn't really any different from revaluing assets even
where there are no currency exchange complications. You carry the
asset in the balance sheet at acquisition cost and accumulated
gain/depreciation, noting its book value as their sum, and when
you revalue it, e.g. you might appreciate an investment property
annually as a particular fraction of book value, the double
entry might be:

Dr £x Accumulated Gain (B/S)
Cr £x Unrealised Gain (P&L)

So, let's look at our German client whose accounts' home currency
would be the Euro. Client gives trader E1k, and trader initially
puts the money into his Euro-bank account.

Cr E1k Client
Dr E1k E-Bank

Trader transfers money to a dollar account.

Cr E1k E-bank
Dr E1k ($1k) $-bank

Trader buys futures.

Cr E1k ($1k) $-bank
Dr E1k ($1k) Investment at cost

Investments double in value.

Dr E1k ($1k) Investment accumulated gain
Cr E1k Client

Investments sold.

Cr E1k ($1k) Investment at cost
Cr E1k ($1k) Investment accumulated gain
Dr E2k ($2k) $-bank

Exchange rate plummets. $-bank balance of $2k revalued to E500.

Cr E1500 ($0) $-bank
Dr E1500 Client

Money transferred to Euro account.

Cr E500 ($2k) $-Bank
Dr E500 E-bank

Money returned to client.

Cr E500 E-bank
Dr E500 Client

Note the sequence of entries on the client account:

Cr E1000 paid in
Cr E1000 investment gain ($1000)
Dr E1500 currency exchange losses
Dr E500 withdrawal

Easy.

 

Easy but wrong. Okay it's not impossible to do these things by double
entry, but is not the *best* method, and so it is not the correct
method. You are being one dimensional again Ronald - "'the accounts
need to be kept in a single 'home currency'".

Why? What possible advantage can there be in having multiple systems
in people's different home currencies? Why not maintain it in *all*
currencies, and keep it live, so that all people can see it and
analyse it in their own currency?

Surely the correct method in this case is not to record the answer but
simply to list the facts. The answer can be obtained from the facts at
any time and in any combination of times. If you want double entry it
can be simulated.

Here's another double entry that cannot be done sensibly:

I pay 200 GBP into my solicitor's Client Account. He writes a check
for 100 GBP on his Office Account (for court fees say) and reimburses
himself from the Client Account.

What is the double entry on the Client Account?



..

 

Careful, you don't want to get confused with Tim the Liar!

 

You'll note that I *did* get back to him, though.

 

I beg to differ.

Well, I agree that double entry may well not be (one of) the best
method(s) for this sort of thing, but you did ask what the double
entries would be.

Poppycock. There's no such thing as *the* correct method, any more
than there is *the* best method.

Not strictly true. I did say that the home currency amounts would
"shadow" the foreign amounts, which do after all exist in parallel,
so to speak, so we do have a second dimension.

To satisfy the requirement that they must balance.

Sure. Fine.

Well, a double entry bookkeeping system is also "fed by the facts".

Agreed. That's why -in my view- there is no need for a computerised
bookkeeping system to maintain T-accounts in long-term storage, as
you would do in an old-fashioned paper ledger system. It is more
sensible simply to store the journal. Then, whenever you need to
generate or print an accounts summary for a particular period, or
a balance sheet for a particular instant, you just run your
accounts program, which sucks in the journal and temporarily builds
all the T-accounts internally (and can even print them out or display
them on screen if you really want to see them), but basically it just
uses the data structures to produce the information summaries you want.

 

Of course, and you were genuinely busy. Is Tim the Liar still claiming
he's too busy?

 

Can't it?

This looks hairier than it really is, because two complications are
involved:

(1) That the client pays in advance.
(2) That the solicitor is presumably bound by rules which say client
funds need to be kept is a separate bank account from his own.

When you strip those complications away, you're left with a similar
scenario to that in which, say, a plumber invoices a customer for
materials and labour separately, where the materials are deemed
to have been bought by the customer straight from the supplier
without passing through the plumber's ownership, even though they
pass physically through his custody, as do the funds, i.e. he is
buying the boiler (or whatever) from the supplier as agent for the
customer. Heck, he may even charge the customer a handling fee in
lieu of what would otherwise be his mark-up. Anything to keep
VAT-able turnover down, eh?

Since the boiler doesn't pass through the plumber's ownership, it
doesn't pass through his P&L. If the plumber is foolish enough
to pay the supplier out of his own pocket, what he's really doing is
advancing money to the customer. So the entry for when he writes a
cheque to the boiler supplier is:

Cr £2000 Bank
Dr £2000 Customer

In due course he will charge the customer £1000 for his labour

Cr £1000 Services
Dr £1000 Customer

and require reimbursement of the outlay. Then the customer
settles his account.

Cr £3000 Customer
Dr £3000 Bank

So, translating this to the solicitor's scenario:

Client pays up front:

Cr £200 Client Troy
Dr £200 Bank Client

Solicitor pays court fee (which is really an advance to the client)

Dr £100 Client Troy
Cr £100 Bank Office

Solicitor transfers funds between his bank accounts

Cr £100 Bank Client
Dr £100 Bank Office

The solicitor might at this stage give you a "statement of account"
which lists the relevant transactions thus:

Cr £200 Advance received: Thank you
Dr £100 Disbursement: Court fees
Balance: £100Cr

 

Well not really, because this is Cash at Bank in the Client's own same
(so to speak), so it is a Debit. Anyway you are absolutely right about
the "Journal" being the only requirement in a computerised set of
accounts, and to see that you must now be a multi-dimensional dude

 

No, there is *also* the solicitor's "Client" Bank account, which is
what you were probably thinking of, but the solicitor's statement
to the client is a summary of a *different* account, namely of the
client's personal account within the solicitor's bookkeeping system.
It summarises those entries (suitably annotated) from the above journal
which refer to "Client Troy", i.e. Cr 200 and Dr 100, in that order,
from transactions 1 and 2, respectively, and so there is a Cr balance
of 100.

The entries in the "Cash at bank in the client's own name (so to
speak)" account (which doesn't actually exist as such) are just a
subset of the entries in the solicitor's "Bank Client" account, in
this case from transactions 1 and 3, which have the same amounts but
opposite signs, i.e. Dr 200 and Cr 100, respectively, leaving a Dr 100
balance.

Must I? The journal is inherently one-dimensional, as it's just a
stream of instructions. It's handy, though, that the instructions
themselves are capable of describing multi-dimensional events.

 

But the Solicitor's Client Account and the Solicitor's Client Bank
Account must always be exact mirror images of each other, so looking
at them in "double entry" is not really sensible.

They appear as a list of Incomings and Outgoings, always with a Debit
balance because they are Cash at Bank, with any Credit balance at all,
evern 1p for 1 minute, a reportable offence devoid of de minimus,
reconciled directly to the Bank Statements.

A bookkeeper in a solicitor's practice has one of the most nerve-
janging accountancy jobs in accountancy..

 

I wouldn't dismiss double-entry systems as non-sensible, and thus
unsuitable for solicitors' practices, quite so easily.

And no, the SCA and SCBA are not mirrors of each other except in
aggregate. There is one SCA per client (or perhaps even one per case,
and one client can be involved in several cases at the same time),
but usually the solicitor would have only one SCBA for all his
clients put together, wouldn't he?

Looking from the outside in, from the point of view of the client, the
SCA looks much like a bank account, and a statement of account issued
by the solicitor to the client would look much like a current account
statement from a bank, i.e. when the client puts money in, it shows
as a credit entry. The only thing special about it is that rules say
it must never be overdrawn, i.e. it must never show a debit balance,
and consequently the SCBA should never show a credit balance (that's
in the sol's books, the statements issued by the sol's bank would of
course never show a debit balance).

Looking from the inside out, the SCA is a liability as far as the
solicitor is concerned, since it is money owed to the client. It's
rather like a trade creditor. This liability is balanced by the
asset which is money in the SCBA.

 

One for every "matter" in the English parlance. For probate or
conveyancing matters consiting of large movements of money there will
often be a dedicated Bank Account, but most often all in one account
as you say, because it is easier to reconcile one big account than
lots of little ones.

But that causes yet another problem for the careworn bookkeeper - Bank
Interest is receivable on these deposits, but how much, and at what
rate?

 

First off, I think for simplicity you have accounts in each currency, for example you have 50 EUR, 25 GBP, and 10 USD in your pocket - keeping track of the egress and ingress for each currency seperately, however in doing a P&L for a period, having all transactions in 'home currency' may be a necessity depending on the purpose of the statement. It's like average people always wanting to know the costs of things in their 'home currency' while traveling abroad, but people who are well traveled and used to dealing with multiple currencies don't pay much attention, the 'cost of things' is only relative to the particular location and the particular currency, there's no need to constantly think backwards, like you're at a restaurant while traveling abroad and a pizza costs 10 EUR and you have 50 EUR in your pocket, who cares how much 'the pizza costs' in USD. People tend to trip themselves up trying to figure out, 'oh these euros in my pocket- let's see i have about 60 USD and that pizza is about about 12 USD something, so i can afford it.' that sort of thing.

Anyhow, I have a related question, as a simple example, the following transactions:

200 MXN + 20 MXN fees => 500 DOP
500 DOP - 50 DOP fees => 10 USD

in terms of calculating gain/loss. clearly we have 220 MXN basis. Let's say at present value it's worth 11.60 USD, so you might have a 1.60 loss. However, it's realistic IMHO to consider the value when the first transaction actually happened. So let's say the value was 9.50 USD 'when' the first transaction happened, end up with a 0.50 gain.

It's easy to calculate realized gain/loss when starting out in 'home' currency, because the basis and end result are in the same currency. So maybe we need a 'shim'.

basis 9.50 USD => 220 MXN
200 MXN +20 MXN fees => 500 DOP
500 DOP - 50 DOP fees => 10 USD

/*shim*/
Cr 9.50 USD // basis
Dr 9.50 USD
/* shim */
Cr 220 MXN
Dr 200 MXN
Dr 20 MXN
Cr 500 DOP /* here's a trip: between currencies */
Dr 450 DOP
Dr 50 DOP
Cr 10 USD

Bal 10 USD
Bal 0 MXN
Bal 0 DOP


But my issue is the 50 DOP fees paid out to end up with 10 USD. You put in 9.50 of value and ended up with an extra 0.50. Looking at it simply, you start with your basis and calculate gain or loss depending on your end result. However, this loss of basis going out in fees is bothering me. I suppose it's possible to have a chain of 50 transfers through various currencies, and disregard all fees in the chain, only considering the basis and the end result - the fees are out the door. The fees are not really deducted from the basis in terms of the final gain/loss.

Comments much appreciated.