This is the sixth and final chapter of a series of blog posts regarding cash reconciliation for accountants. Below are all topics included in this series:
In the last chapter, we used a real-world example to illustrate how to perform a cash reconciliation. However, there are many other nuances that can complicate this process. In this chapter, you will learn how to tackle the 5 most common problems when performing a cash reconciliation.
In today’s global economy, companies almost always operate in more than one currency: Companies sell to customers all over the world, intercompany transactions between subsidiaries, and interactions between the company, banks, and payment processors, just to name a few. Although they are just normal business activities, these transactions cause currency differences on various levels.
Before we go over an example, below are relevant terms you will need to be familiar with:
Transaction Currency: This is the currency in which the transaction originated in.
Functional Currency: IFRS Standard IAS 21 and FASB ASC 830-10-45-2 define functional currency as “the currency of the primary economic environment in which the entity operates (ie the environment in which it primarily generates and expends cash).” It is also the currency that the entity or company would use to report stand-alone financials. Companies can have more than one legal entity with different functional currencies per entity.
Settlement Currency: Also known as payout currency, settlement currency is defined as the currency used by the bank account and the payment processor.
In the following example, determine the appropriate transaction, functional, and settlement currencies Widget Company should use.
Widget Company is an online store that sells one-year subscriptions for access to Widget’s photo editing software. Widget currently only sells its products in the US, Canada, and Australia, and allows customers to complete purchases in one of three currencies: USD, CAD, AUD.
Widget’s Legal Entity structure requires all customers in the US and Canada to be recorded in the US-based subsidiary (Wid-US), while all customers in Australia are recorded in the International subsidiary (Wid-Intl). Financial statements for Wid-US and Wid-Intl are prepared in USD and AUD, respectively. Widget’s payment processor and bank both only operate in USD.
On 3/1, a customer located in Perth, Australia purchased a one-year subscription for $100 and elected to pay in CAD.
Transaction Currency: $100 CAD
Although the customer is in Australia, he can opt to pay in USD, AUD, or CAD. This customer chose to pay in CAD.
Functional Currency: $109.94 AUD
Because this customer is located in Australia, the sale must be recorded in the international subsidiary (Wid-Intl), which has a functional currency of AUD. Exchange rate on 3/1 is 1 CAD to 1.0994 AUD
Settlement Currency: $71.72 USD
The payment processor and the bank operate in USD. Therefore, the payment processor will be required to convert the $100 CAD into USD in order to deposit the cash into the bank account. Exchange rate on 3/1 is 1 CAD to 0.7172 USD
Note: For simplicity purposes, we are ignoring processing fees in this example.
When there are foreign currencies, there will be foreign exchange (forex or FX). As shown in Example #1, the 3 different currencies all require FX rates depending on the interaction.
FX rates fluctuate day over day. Changing FX rates will also impact a company’s realized gain/loss on its financial statements.
Realized gain or loss indicates that the customer has settled the invoice or that the company has settled the refund. FX gains and losses are primarily driven by changes within the functional currency. Gains and losses are reported on the income statement, therefore FX differences in functional currency (the currency used to prepare financial statements) will be the primary driver of foriegn exchange.
In the following example, determine the appropriate journal entries to be booked to the general ledger.
On 3/1, a customer located in Perth, Australia purchased a one-year subscription for $100 and elected to pay in CAD. On 3/5, the customer cancels the subscription and receives a full refund.
The exchange rate on 3/1 is 1 CAD to 1.0994 AUD.
The exchange rate on 3/5 is 1 CAD to 1.0810 AUD.
| Date | Account | DR | CR |
|---|---|---|---|
| 3/1 | Cash (FX 1.0994) | $109.94 AUD | |
| Deferred Rev (FX 1.0994) | $109.94 AUD | ||
| 3/5 | Deferred Rev (FX 1.0994) | $109.94 AUD | |
| Cash (FX 1.081) | 108.10 AUD | ||
| FX Gain | 1.84 AUD |
As seen in the real-world example in Chapter 5, timing differences across the various financial systems will cause differences in cash. These typically include differences between Billing System/RevRec System and Payment Processor payouts, as well as Payment Processor payouts and Bank cash.
These timing differences become more prevalent in companies with small dollar, high transaction volumes. Therefore, it is essential to perform a cash reconciliation to identify the reconciling items across each report.
Timing differences are often tedious to identify at month-end, especially when cash reconciliations are performed manually. Companies must consider automating their cash reconciliation and cash matching process to decrease risk of manual errors.
When performing cash reconciliations at the aggregate-level, it is possible that you may not be able to identify differences down to $0. In such instances, accountants must define allowable differences an acceptable threshold.
A threshold of <1% may be appropriate for some SaaS companies but not others. To establish threshold levels, accountants need to rely on professional judgment and general rules of thumb. They must also consider the dollar amounts, percentage, and risk of material misstatement. An auditor’s opinion may be helpful, but ultimately it is the accountant who must determine the reasonable threshold.
Remember that it is all relative.
Companies with subscription business models typically have high transaction volumes, making transaction-level cash reconciliations extremely difficult without automation or finance tech stack modernization.
When dealing with high transaction volumes, aggregate reporting is usually the default for accountants because they do not have a cash matching system. Aggregate level reporting (as described in the examples above) allows accountants to perform high-level cash reconciliations and obtain comfort that sales and cash across an entity’s financial systems are complete and equally accounted for. However, aggregate reporting does not allow accountants to drill down into specific transactions to easily identify discrepancies and reconciling items.
An ideal cash reconciliation is performed at the transaction-level. An automated cash matching system will be able to link cash from the various financial systems at the transaction level and identify specific differences. With transactional-level reporting, companies can reconcile on the lowest level so discrepancies and reconciling items can be reduced to $0.
This concludes our Cash Reconciliation Blog Series! Cash reconciliation can get quite complex for high growth companies with large transaction volumes. Many of our customers struggled with these same issues above before partnering with Leapfin. Leapfin helps accountants automate cash reconciliations, cash matching, and transaction-level reporting. Our platform also covers revenue recognition and COGS.