JDE FX Rates and Internal Controls
Introduction
You are implementing JDE Multicurrency, and the internal controls topic comes up, with specific concerns about users having the ability to override the FX rate that JDE defaults in entry screens.
This is a quick guide to help you through this process so you can go live with the right controls in your multicurrency project. It includes internal controls terminology that can facilitate the discussion with accounting and/or the internal controls team.
Background on JDE multicurrency functionality
When a foreign transaction is entered in JDE (journal entry, payable, receivable, purchase order, PO receipt), JDE defaults the FX rate based on the daily FX rates table (F0015). However, users can override this default FX rate, which is very convenient to handle exceptions but can also raise concerns form a controls point of view. Once the transaction is posted, the FX rate is locked and cannot be updated any longer.
There are business scenarios that will sooner or later require users to override the rate. As an example, you may need to create an adjusting entry or reclass in the current period, for a foreign payable entry that was originally created and paid in a prior period. In this case, you may want to override the FX rate of the adjusting entry or reclass to match the rate of the original foreign payable.
Background on Internal Controls
When discussing internal controls with business areas and accounting, please keep in mind these high-level guidelines:
Look at the whole process, beyond the specific step or risk under discussion. When you look at the complete process flow, you may find out that there are other controls that offset the risk in a specific step of the process. As an example, you may realize that the posting control offsets the risk of users overriding the FX rate, as long as you can ensure that people who are posting are reviewing the FX rate.
Having more controls does not mean better overall control and can compromise efficiency. You are aiming for fewer key controls that ensure data accuracy while allowing efficiency in the process.
Alternatives: Preventive controls
1. No additional JDE security
Allow users to override the FX rate when they create transactions and evaluate if the posting controls compensate this risk. This should be fine as long as people who are posting batches are checking the foreign and local currency amounts.
2. Implement additional JDE Security
You can implement standard JDE security (column security) to gray out the FX rate in the General Ledger, Accounts Payable, Accounts Receivable screens (Purchase order and PO receipts screens as well depending on the modules you use).
By doing this, users won’t be able to override the default FX rate. However, there are many drawbacks to this alternative:
There will be business scenarios where users will need to override the rate, so you will still need to provide access to override FX rates to some key users. These key users will need a special JDE security role that allows them to override the rate.
Getting so detailed with JDE security will mean more administration work, for both IT and accounting, when JDE users are hired, transferred, promoted, etc.
More work to test all your AP, AR, and GL entry screens and to make sure that this security feature does not negatively impact functionality.
3. JDE transactional data-entry screens
There are JDE processing options available which, if enabled, will warn users with a soft error if they override the default FX rate to a rate that is above a predetermined tolerance percentage. This is standard configuration, available in the General Ledger, Accounts Payable, Accounts Receivable and Purchasing modules (PO and PO receipts). For example, if you set tolerance to be 5%, and a user overrides the FX rate over 5% of the default daily rate, then JDE will show a warning. The user can acknowledge the warning and still save the transaction if required.
This alternative is very simple to setup, and hardly needs any testing since this is JDE standard functionality.
Alternatives - Detective controls
4. Report to validate exceptions
Create a JDE report that shows transactions created with a rate different than the daily default rate. This can be easily handled through a DAS report, which would run at month-end, and there would be a follow up with the originators of these entries to ensure the rate used is correct.
If you would like to know more about ReportsNow Data Access Studio (DAS) or are unsure on how to create this report, please don’t hesitate to Contact us!
Data Access Studio DAS
Automatic vs. Manual entries
All the alternatives above are focused on foreign transactions entered manually. Don’t forget about all your integrations/interfaces. For any automated entries, ensure the integration software is using the same logic that JDE uses to populate the FX rate in Z files or EDI files. Ensure the integration/interface is using:
the same date as a source as your JDE configuration: G/L date, invoice date, or order date,
the same source for FX rates: JDE F0015, and
the same JDE logic: get today’s FX rate based on G/L date, invoice date, or order date, and if not found then get the closest FX rate to today (less than today).
Recommendation
Avoid going directly to alternative 2, which is implementing additional JDE security. First, consider the drawbacks listed above and the other alternatives.
Evaluate if your posting controls are sufficient – alternative 1.
If posting controls are not sufficient, evaluate implementing alternative 3, or alternative 4, or both!
Consider making alternative 4 a key control to document exceptions.
Alberta ERP Projects and Solutions
Please let us guide you through your multicurrency implementation and/or any other JDE needs.
