Augmented Currency and Exchange Rates

I. COMPANY BACKGROUND:

PQR Inc is a multinational company and a solution provider for the built environment for real estate, integrated technology systems, and the physical and digital assets they connect. PQR Inc has multiple SAAS products catering to the needs of multiple industries like Corporate, Education, Healthcare, Manufacturing, Retail, etc. With these multiple solutions, PQR Inc provides implementation, managed, and training services.

PQR Inc has multiple legal entities across the US, Europe, and the UK. And they use Zuora Billing for invoicing and Zuora Revenue for Revenue recognition. The billing system is the upstream system for Revenue and is set up as a single US-based entity.

II. SCENARIO:

Zuora Revenue has the following standard mapping for currency-related fields:

Since Zuora Billing was set up as a single US-based entity, the functional currency flowing to Zuora Revenue was always USD irrespective of the legal entity.

And currently, information regarding legal entities (Entity ID) is flowing on custom fields in Billing and Revenue.

III. ISSUE:

PQR Inc expects to process all its transaction considering the entity’s base/functional currency, which means the functional currency and the exchange rates should be based on the Entity ID Number populated on custom fields. As mentioned above, as per the standard mapping transaction currency will be the currency chosen at the customer level and functional/base/home currency will be the Entity’s Home currency in Billing. In this case, this home currency for PQR Inc will be USD and the exchange rates are daily rates populated based on the document date/SO date.

Below is an example of actual and expected data flow:

i. Actual Data:

ii. Expected Data:

IV. RESOLUTION:

We sequentially built the following data augmentations to meet the expectations of PQR Inc:

i. Populate Function Currency

Based on the Entity ID, functional currency (EUR/USD/GBP/BRL, etc.) was populated in Zuora Revenue. PQR Inc had 20+ legal entities and accordingly using the lookup rule of data augmentation the functional currency was replaced.

ii. Populate Functional Exchange Rate

Based on the functional currency populated in #1 above and the transaction currency flowing from Billing, the functional exchange rate was populated. This data augmentation is a SQL query that uses the standard Zuora Revenue exchange rate tables as its base. Based on the rates, PQR Inc was able to report its revenue in the functional currency as well.

iii. Populate Global Exchange Rate

Based on the functional currency populated in #1 above, the global exchange rate was populated. This data augmentation is a SQL query similar to the one in #2 which uses the standard Zuora Revenue exchange rate tables.

Using the above data augmentations PQR Inc was able to account for and report all its transactions in accurate currencies. The above solution would be helpful for all companies whose upstream is set up as a single entity but would still want to account for and report their revenue in functional currency.

Did you find this article on ASC 606 case study helpful?

We will be happy to answer any questions/queries regarding this and any other topics regarding ASC 842, IAS 17, IFRS 16, IFRS 15, Revenue Recognition and ASC 606.