Balmori Software Inc.

[ Article ]

Does your company do business in two or more currencies? If so, then you must have at some point considered acquiring “dual-currency software” or “multi-currency software.” But before you travel too far down that road, pause a while and reflect on the big picture.

Working in a dual-currency or multi-currency-transacting business, you know by now that one currency is your "functional currency," the other(s) your secondary currency(ies). Philippine Accounting Standards No. 21 (PAS 21) prescribes this treatment.

A functional currency is the currency of the primary economic environment in which a company operates. This is not necessarily the currency of the country in which it is physically situated.

In 2006, the Philippine Securities and Exchange Commission (SEC) lightened your burden a wee bit. It eased the rules for Philippine-based companies shifting their functional currency from the peso to something else.

Qualified companies no longer need SEC approval to shift to functional currency reporting. They now just need to notify the SEC of their intention to do so. (SEC Memorandum Circular 1, Series of 2006: "Guidelines on the filing of functional currency financial statements" (dated 15 December 2005).)

So that's good; less red tape.

But why is a 2006 SEC ruling of interest now, so many years later? Actually it's of interest at all times because the problems of reporting multiple currency transactions are the same, regardless whether the reporting company uses an exotic currency or sticks with the Philippine peso as its functional currency.

As long as you're transacting in more than one currency, the accounting problem is the same - with or without SEC Memorandum Circular 1 - 2006.

Why in the first place would a Philippines-based company want to use a functional currency other than the peso? Here's why. In practice, a firm would want to shift to a non-peso functional currency if the bulk of its transactions are in that non-peso currency.

Mind you, not its most numerous transactions, but rather, those transactions that make up the bulk of the value of all its transactions.

Examples of companies in this situation are Export Processing Zone locators and certain exporters. As of February 2014, there were 300 special economic zones in the Philippines, with thousands of locators. Being mostly manufacturing firms, for sure they all have lots of foreign currency transactions.

Let's examine this interesting relaxation of a bureaucratic rule. The SEC takes its cue from Philippine Accounting Standard 21: "The Effects of Changes in Foreign Exchange Rates."*

Let's see what PAS 21 says about functional currency reporting. Let's consider a hypothetical company - Djumongous Manufacturing Co., a maker of widgets for hard disk drives in the Rosario, Cavite EPZ.

Djumongous Mfg. has determined that most of its sales and raw materials purchases are in US dollars. And these make up most of the value of its transactions. So the company decides that it makes sense to present its financial statements in USD instead of PhP.

First, when Djumongous adopts the US dollar as its functional currency, the roles switch. Djumongous now starts keeping its books in USD. From Djumongous's point of view, it's now the Philippine peso that henceforth gets treated as the foreign currency.

Whenever there is a peso transaction**, the usual expectation is that Djumongous's bookkeeper should convert the peso amount to USD. Then he books the transaction in USD into Djumongous's subsidiary ledgers (PAS 21, paragraph 21).

This is the same thing Djumongous was accustomed to do when the peso was its main (i.e., functional) currency, and the USD was the foreign currency. Except now the currencies have swapped roles.

And so Djumongous Mfg., peacably going about its business, produces a dollar denominated balance sheet and income statement each month. And all's well with the world.

But in practice, the PAS 21 raises an implementation challenge. It's this: Exactly how in day-to-day practice do you go about converting transactions in the secondary currency into the main (functional) currency?

At first blush, it seems intimidating to have to examine each transaction, convert it from peso to the functional currency, then book it. That seems like a major time-burner. A major new burden on the bookkeeping staff.

But is it, really? Let's break it down.

A. Exactly what items do you need to convert?

Remember, the peso is now the secondary currency (in our example); and the USD is the functional currency. Every single peso transaction is now by definition a secondary-currency transaction for this company. Therefore Djumongous Mfg. should convert all its peso-denominated transactions to USD, the primary – the functional - currency.

These peso transactions include depreciation charges, peso payments for purchases of local materials. Peso salaries and wages. Employer contributions to SSS/ PHIC/ HDMF, petty cash disbursements, etc.

B. A sensible journalizing technique (hint: use subsidiary ledger summaries)

Converting secondary currency transactions into the functional currency looks like a tedious task. That is, if you take the view that you've got to translate each and every transaction you transact, into another currency.

But it doesn't have to be that way.

Djumongous Mfg.'s chief accountant can cut out the tedium and save plenty of time by remembering one simple phrase. Grand totals.

Just for discussion's sake, let's go low-tech for a little while. We'll assume that Djumongous Mfg. has no special software to handle its subsidiary ledgers; it uses just an electronic spreadsheet.

The chief accountant can summarize secondary-currency transactions within a spreadsheet app, and then convert just the grand totals to the functional currency. The heart of the technique is to convert just the grand totals to the desired currency.

The chief accountant then journalizes the converted grand totals to the general ledger module. (If Djumongous were a Balmori Software user, that would be our SURE! GL module).

For example, the chief accountant journalizes just the grand total of all peso disbursements for the period, not every individual peso disbursement transaction. He journalizes the total of all peso purchases, rather than each individual peso purchase transaction. He journalizes the total of all peso collections, rather than each individual peso collection transaction. And so on.

Here's the key to this approach. The chief accountant continues to maintain the peso transactions in peso-denominated subsidiary ledgers. So, no extra work here. Then, as already stated, he totals up all the peso transactions and produces a peso grand total for each SL. He converts only these peso grand totals into the functional currency - the US Dollar. Then he journalizes these USD grand totals to the GL.

Simple. Elegant.

What about the dollar transactions? Common sense: the accountant would maintain those in separate, dollar-transactions-only subsidiary ledgers, of course. And would journalize - you've got it - just the grand totals into the general ledger. But these, being already in the functional currency, wouldn't need conversion.

But what if this company had both US dollar sales and peso sales (or both dollar purchases and peso purchases)? Why, then, the chief accountant would maintain a dollar-sales ledger and a separate peso-sales ledger. (Or a dollar-purchases ledger and a separate peso-purchases ledger). And he'd only convert the peso SL totals to the functional currency at the end of the month.

By focusing on just grand totals, the bookkeeper's work has just gone from tedious and intimidating to quick and painless. And all without needing a “dual-currency software.”

The spreadsheets listing the detailed peso transactions will serve as the supporting schedules for the journal entries.

So we come to this realization: thinking you have to journalize every single transaction into the GL is what makes it look like you have to convert each and every secondary currency transaction to the functional currency. Which in turn makes it appear that only a multi-currency software can let you comply with PAS 21 rules. This is a fallacy.

With the summarization approach, you'll need to convert very few transactions to the functional currency. You'll only convert the grand totals of each SL, not each and every transaction.

And you'll deal with just a handful of grand totals. That's because you have only a handful of subsidiary ledgers to take into the GL. And so journalizing this handful of SL subtotals takes just a few minutes every month-end.

This is a practice familiar to all classically trained accountants. Therefore, you've simplified the currency conversion challenge into a non-challenge. All you had to do was observe the textbook practice of maintaining subsidiary ledgers.

No need to use an expensive and difficult-to-use multi-currency accounting application.

With this technique, you've addressed your currency conversion problem. With elegance.

C. Going one step further: a software solution for a different but related problem

At this point, you've fully handled your currency-conversion problem. Now a separate but related problem reveals itself.

The spreadsheet-based solution just described in section B has a downside. And it's this: the spreadsheet itself. Maintaining the subsidiary ledgers remains tedious if our chief accountant continues using just a spreadsheet application. (Subsidiary ledgers include the A/R, A/P, Purchase Book, Sales Book, Collections Book, Disbursements Book, Customer Ledger, Supplier Ledger, Inventory, etc.)

Why is a spreadsheet approach still a tedious solution? Didn't we just see it enable a sound approach to functional currency reporting? It's tedious because the spreadsheet-as-subsidiary-ledger approach still involves too much time-consuming clerical work. Let's examine it.

Using a spreadsheet, the bookkeeper still has to record each individual transaction into each affected book. For example, he records a collection transaction in the Collections book (or column). Then he updates the A/R book (or column) to reflect the collection's impact on the receivable.

Then he updates the Customer Ledger to reflect the same collection. And then he updates the Withheld VAT/Tax book (or column).

Yes, all by hand - he's still typing each update to each SL. Yes, still one SL at a time. And yes, he's doing this even though he's not converting each individual transaction to a different currency. (Remember, he's doing currency conversion only on the grand totals of each SL.)

This example reveals two difficulties in maintaining your subsidiary ledgers with a spreadsheet. (a) A spreadsheet is not an integrated solution. For all its advantages, one thing it doesn't do is to synchronize all your subsidiary ledgers automatically.

And (b) A spreadsheet lacks built-in error-trapping. An encoding mistake at any one of those update points will introduce discrepancies among SL's that ought to be always mutually consistent.

Indeed, synchronization of books - not currency conversion - is the real problem needing a computerized solution here. Currency conversion? You've already addressed your PAS21 reporting concerns through the technique described in section B above.

It's for a different motivation that you'll want to computerize your subsidiary ledgers. It's to remove the inaccuracies and the reporting delays that come with maintaining your books manually. (We consider using spreadsheets for bookkeeping still a manual approach to subsidiary ledger maintenance. You're just using the computer as a glorified typewriter.)

Therefore the punchline is this: Maintaining subsidiary ledgers is the task that's crying out to be computerized.

D. Get thee a subsidiary ledger software solution

Let's now examine this real concern. How do you synchronize your subsidiary ledgers without relying on error-prone manual procedures? (Remember, the spreadsheet method is still pretty much manual processing.)

This is how: you deploy a software solution specifically designed to handle subsidiary ledgers. Sounds obvious? Let's see.

This software solution should have the following minimum capabilities: (a) Built-in error-trapping, for obvious reasons. Next, (b) It should not allow a user to casually modify its algorithms - which he could do in a spreadsheet, to everyone's grief.

And most importantly, (c) it should automatically synchronize all books that could possibly be affected by a transaction. That's what's known as an integrated solution.

CONCLUSION. A company transacting in more than one currency can adopt one or both phases of this two-stage approach. First, a cost-free, process-and-procedures-based phase. Then, if it likes, a computer-assisted phase as well.

It's a robust, long-lasting, cost-effective solution to the reporting requirements of PAS 21. Our hypothetical company satisfies PAS 21 by converting into its functional currency only the grand totals of secondary-currency transactions. And it journalizes only these converted grand totals to its GL.

Our multi-currency enterprise could stop right here. It would have already met its currency conversion reporting obligations.

But what if this company wants to go further? What if it wants to reduce errors and reporting delays that degrade its efficiency and ability to move fast? Then it would do well to computerize its subsidiary ledgers with an integrated software solution.

And so we come to the crux of the issue: the big back-room problem that's crying for a computerized solution is not the having to deal with multi-currencies. It's synchronizing your subsidiary ledgers so that you have the foundation for a usable MIS.

(Many thanks to Joy Reyes of Kapco Manufacturing for her valuable inputs during the writing of this article.) - rsr

------------------------------

* PAS 21 is based on IAS 21 (International Accounting Standard 21)

**For more nuance, read the sidebar "For the nerds"



Title:  Doing business in dual currencies? It's not dual-currency software you need
              Attention exporters and EPZ locators: Don't let a superficial reading of PAS 21 seduce
              you into a bad software choice




Share on

                                                                

---

<<< Back to top >>>