JD Edwards is a powerful system and the financials features can make running your business financials a smooth and automated process. But, the amount of data needed to keep these systems running can be overwhelming, and things can get out of whack easily if not properly monitored. Here are a few common problems we’ve seen with JD Edwards financials and how to either prevent them from happening in the first place or how to reconcile the issue after the fact.
Are you still suffering through the manual cash application process? If so, it’s time to step up your game. The manual cash process means that your company still gets checks sent directly to the office or, if you are using a lock box, you receive copies of the checks sent from the bank. This process is complicated by all the other forms of payment your company accepts, such as credit cards and PayPal. When working with JD Edwards, the best solution is to automate the entire process.
Instead of receiving paper copies of checks or a report of remittances, the bank and credit card companies transfer a file that is then picked up in JDE and processed through automatic payment application algorithms. These algorithms are sophisticated enough to allow control over how receipts are matched to invoices and whether or not you apply unapplied cash to a customer’s account. The precision of the match is controlled by the algorithm and can be configured for a range of options from specific invoices and amounts to matching on a balance forward. Small differences can be written off automatically based on company policy so your staff is not bogged down manually clearing small hanging balances.
Utilizing the automated cash applications feature is much more efficient than the manual process, as those employees who were manually entering information for cash application are now free to focus on discrepancy resolutions and collections. If the process is configured correctly, it is more accurate than a manual process. In addition, when using a lock box for cash payments, the lock box gets the cash into your bank account sooner than receiving payments at the office.
Clients who have implemented automatic cash application typically see match rates in the 75% to 80% range. Some have experienced match rates as high as 95% with changes to their invoice and lock box processes geared towards incentivizing customers to provide invoice information on their remittances to improve the matching process.
JD Edwards financials has two crucial files: the General Ledger (GL) Transaction File, and the Trial Balance File. The GL Transaction File is a detailed account of general journal transactions, while the Trial Balance File is similar to a spreadsheet with monthly balance columns; one line per account, per fiscal year, per ledger type. These two files should be in sync at all times. If the Trial Balance File is out of balance or out of sync to the Transaction File, your JD Edwards financial statements will be wrong.
During a client project, the client’s Trial Balance File was not lining up with their GL Transaction File and they couldn’t figure out why. This is an issue that we have certainly seen before, as it can be easy for things to slip under the radar and throw the GL and Trial Balance Files out of sync, thus wreaking havoc on your financials. Here are a few of the reasons your GL Transaction and Trial Balance Files could be out of balance.
In the post process, JDE takes the amount from the GL and uses that amount to update the appropriate balance in the Trial Balance File as well as create an automatic offset. If a post job is cancelled in the middle of running, however, it won’t be able to complete the Trial Balance File update or create the automatic offsets.
A cancelled posting job is typically the result of human intervention. For example, in the client project we were working on we found that their nightly post jobs were being delayed and were still running when the team started work the next day. They couldn’t start operations while those files were still posting, so team members were cancelling the post jobs before they were complete in order to get the day started. Once that was identified as the cause for the unbalanced files, they were able to make changes to the nightly schedule so all the jobs finished in time, preventing the files from being unbalanced in the future.
While cancelled post jobs is human error more often than not, there are occasional instances when JDE can’t create the automatic offsets and the batch will fail the post. Typically, however, the system will catch that and error the batch out instead of forcing it through and throwing your Trial Balance File out of balance. However, older versions of JDE require that a post job be single threaded, meaning that only on job can be running at a time. While that isn’t a concern for newer versions, if you are running an older version of JDE keep in mind that not running your posting jobs single threaded can put your Trial Balance out of balance.
Another situation that can put your Trial Balance out of balance is manipulating data in the GL Transaction file in order to get an entry to post. Sometimes an entry with a prior period general ledger date may not be posted in the period recorded, but won't be found until a later period. The temptation is to go into the Transaction File and change GL dates. We always recommend against this because if not done correctly, the change can cause integrity issues. It is far better to post the entry as is in the prior period and then book the correcting entries needed to adjust to the desired outcome.
There are two things that need to happen during the month end close to ensure that your files are balanced. The first is to make sure that all GL Transaction Files are posted. The second is to make sure that the companies within the Trial Balance File are balanced. We recommend running JD Edwards integrity reports throughout the month to catch these errors before month end, giving you more time to analyze the error and determine the correction.
If you have your financials set up correctly, the GL Transaction file and Trial Balance should stay in sync and in balance, allowing you to complete efficient, error-free month end closes.
You probably have multiple people entering data into your JDE system, and keeping that data organized and the system operating efficiently takes some maintenance. One way to keep up with the data is through the month-end reconciliation process.
A perpetual inventory that is not reconciled to the General Ledger can result in significant internal control and audit issues. There are many complexities in the inventory reconciliation process, one of which is the costing method used. Some costing methods generate variances that may or may not be recorded in the General Ledger. Another facet of the issue is the possibility that some transactions that effect quantities may not go through to the General Ledger correctly. These variables are often what make the inventory reconciliation process difficult.
Over the years, our financial and distribution consultants have developed an accurate and efficient process for reconciling the CARDEX and item balance file to the General Ledger.
This process involves using the detailed transaction records in the CARDEX and tying them to the inventory item perpetual balance file. The resulting reconciled number is then tied into the General Ledger. This ensures the integrity of the inventory system.
The process can be completed during the close, ensuring accurate month end reporting.
One of the most difficult accounts to reconcile, particularly in older versions of JD Edwards, is the received not vouchered account. Until recently, JDE did not have a native process to accurately support the balance in the General Ledger. JDE has done a lot of work around making this process smoother, but it is still no easy task.
One of the most frequent reasons that this is thrown out of balance is, again, human error. People do things such as incorrectly reverse or void a voucher, which then reverses the General Ledger transaction but does not reverse it on the purchasing side. Landed cost (any and all costs associated with getting a product to the dock), can also cause problems. Not all landed cost transactions are included in the JDE reconciliation report, which creates discrepancies during the Received Not Vouchered Reconciliation process.
We have worked with clients to develop automated processes that identify variances between the General Ledger and the receipts file. By automating variance identification processes, the variable of human error is eliminated, leading to more accurate reports.
Both Inventory and Received Not Vouchered Reconciliations need to be completed on a month-to-month basis because once they are out of balance it is incredibly difficult to go back and reconstruct what went wrong. Part of the responsibility lies with the finance team, who needs to be diligent and make sure that they are reconciled each and every month. Aside from a capable finance team, reconciliations require someone who truly understands the nuances of the inventory system as well.
These are just a few of the ways that you can stay on top of JDE financials to ensure that things run smoothly. There are so many more details and functions available, so if you have a specific question about how to make JDE financials work more efficiently for your organization, drop us a line.
No Comments Yet
Let us know what you think