Open navigation

Multi-Currency

TABLE OF CONTENTS


K4X

Please keep in mind, this functionality is only going to be available to the "Kahua for X" (Owner, GC, K-12) packages. If you have custom extension you may not see this functionality. 


Adding Currencies

To make a currency available to a project or program, it must be added at the top level (domain) partition first.

To add a currency, go to the “Currency” tab of the configuration application.




On the “Rates” subtab, click “Add” in the Exchange Rates table.


In the resulting modal, select which currency to add and click ok.


The new currency is now usable in all projects within the domain.



Creating Rate Types

Rate types can only be created at the domain level partition. To create a new rate type while in the domain level partition, go to the “Rate Types” subtab and click “Add”.



A new rate type field will be added to the table.


Once saved, the new rate type will be configurable on the “Rates” subtab at the domain or project level (Note, the configuration app must be closed and reopened for the new rate to appear on the “Rates” tab).


Unlimited rate types can be created.  The Baseline Rate Method uses two special rate types for business processes. These two special rate types are seen on the Currency/ Rates configuration screen.  


The initial rate type that came pre-configured with Kahua will always be designated as the Baseline Rate. It can never be deleted. Its exchange rates cannot be edited once documents are created using that currency within the configuration boundary.  


Any rate type can be designated as the Floating Rate on the Currency/ Rates subtab.  However, only one rate type can be the Floating rate at any time. 

 

See Baseline Rate Method below for more details.



Updating Exchange Rate Types

Exchange rates can be updated for each rate type of each currency at any partition on the Rates subtab of the Currency tab of configuration.  Note, baseline rates for a currency lock in a partition after a cost document using that currency is created. This is discussed further in the next section.

 


Baseline Rate Method

Kahua For Owner, Kahua for GC and Kahua for K-12 domains use the Baseline Rate Method. In the baseline rate method, baseline exchange rates will remain constant for the life of the project. This approach leverages the idea that a project’s budget is set up assuming certain exchange rates.  We use those rates for all day-today project cost management to simplify working with different types of numbers such as commitments, budgets, and actuals.


Baseline exchange rates are locked once any document is created using that currency within that configuration boundary.  Meaning – within the current partition, or a child partition inheriting that same Rate Type configuration.


The implication of this rule is – shortly after a project is set up, the Configuration/ Currency/ Rates should be set to Override.  Otherwise, editing baseline rates at the domain or program level becomes impossible. 


To overlay the impact of currency changes compared to the baseline rate, Kahua provides the tools to capture, forecast, and review the gains and/or losses due to exchange rate movement.   Users can decide how they wish to account for these gains and losses by manually squaring up the impact if required.

There are two exceptions to using the fixed baseline rates, leveraging a concept called the floating rate:

  • Capturing the real payment amount during the pay request, pay app and invoice process.
  • Using the Floating Rate to help calculate the exposure the project has to future fluctuations on an exchange rate gains (loss) report.


A recommended domain configuration, for domains using the baseline rate method approach to multi-currency, is shown below:

  • Rename Current Rates to Baseline Rates to simplify terminology AND
  • Add Floating Rate type:


  • Set the new rate type as the Floating Rate on the Rates configuration:
  • NOTE: the system defaults the baseline rate as the floating rate in the Rate Types grid above.   If it is left that way, all gains/ losses will default to ‘no change’.


New Projects (Partitions)

As noted earlier, “the baseline exchange rate cannot be edited after a document uses that currency within that configuration boundary”.   


If a project still inherits the Configuration/ Currency/ Rates from their parent, those exchange rates can’t be edited at the parent level.  This may be desirable in some cases, such as program using all the same exchange rates.  

BUT – a single document on a project still inheriting the Rates configuration from the Domain will lock the baseline exchange rate at the domain.

Recommended practice is to override the Configuration/ Currency / Rates at the project level as soon as practical. 

 


Floating Rates

Floating rates are used in two places with the baseline rate method:

  • The Multicurrency section on pay apps, pay requests and invoices (after 2021.3.0515) when the contract is a different currency than the project:
    1. The floating rate is used to calculate the Estimate Payment in project currency, allowing to estimate the Floating Gain (loss) for the payment document. As the floating rate changes, the estimated payment changes until the user (or system) enters a Real Payment amount in the system.
    2. The floating rate provides the default value for Real Payment amount with payment document is set to Paid, but only if the Real payment amount is empty.  
  • (Future) Forecasting gains (losses) for all the yet-to-be-locked in spending in another currency. This includes unpaid payment documents, un-invoiced commitments, open budget in that currency not yet committed.  
    1. These appear in the gains (loss) reports.

Floating rates are envisioned to be update regularly as part of the overall cost reporting process. There are no restrictions on editing floating rates. 


Exchange Rate Gains (Losses)

When buying work in different currencies, rate fluctuation may impact the real cost of buying that work compared to baseline rates used on the projects.  


To reflect that difference in a Kahua project, treat it the same as any charge on the project. Create appropriate WBS and activity codes, and charge the project using existing cost documents. For example, create a contract then ‘charge’ the project each month with a simple change order to reflect the real gains/ losses.

Where does this gain/ loss information come from?

Frequently, your corporate accounting system can tell you the information you need. If integrations are in place, some automation may be available.

If you capture the Real Payment costs for payment documents, the system will calculate the real gain (loss) per document when it is paid.  

  • If the floating rates are updated regularly, then each time a payment document is marked Paid, the system will log the Real Payment amount for you, simplifying the gain (loss) process.

Finally, if you wish to calculate the forecasted gain or loss for everything not-yet-paid, estimate the total planned spending in that currency, subtract value of the payment documents create, and multiply by the difference between the baseline rate and floating rate.

NOTE: a report for this Gain (Loss) Calculation is in the planning stages.  

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.