Nope. Not your spouse’s birthday or you wedding anniversary, but dates in Sage 100. Those dates are important, but that is for a different blog altogether.
Many years ago I had a new client panic in the middle of doing a period end update because they had forgotten to set the module default date properly (in their mind). In their panic they hit the power switch to stop it from completing the period end processing. Ouch! Never mind the fact that setting the module default date was not important, it was no fun recovering from that incident. A little better understanding of dates would have avoided a lot of pain.
So let’s talk about what I consider to be the three major types of dates in Sage 100.
The Module Default Date
You should all be quite familiar seeing this window pop up.
This is the default date value that will be used as you enter transactions into the system. It is most useful if you might be doing data entry for last Monday and you want the date to always pop up as Monday’s date instead of today’s date.
This is very useful to do when you are working in bank reconciliation. Set the module date to the bank statement date before you start clearing checks.
You can also see the module date on the far right of the status bar at the bottom of your launcher. If you click on it, you can change the date for the displayed module.
This is the date my client panicked about when doing period end processing. It really had no impact on period end processing. There are a few areas in Sage 100 where this has an impact on processing but they tend to be rare. Period end processing is not one of those situations.
The Document Date
The document date is the date that is printed on a check, a sales or payables invoice or any other number of documents. As you are doing your data entry, it will default to the module date previously discussed, but you can override it.
This is NOT the date that it will post to the general ledger!
Of course with every rule there are exceptions. A general journal date and a deposit date in cash receipts entry will post to the general ledger based on the document date.
The Transaction Date
The transaction date is the date that any given journal will post to the general ledger. You will normally see this when you go to print and update your journals. Once again it will default to the module default date, but it can be overridden.
Getting In Trouble With Dates
Who out there on January 3rd (after that nice holiday weekend) hasn’t come back to work and started processing transactions for 2017, and accidentally used 2016 or vice versa? I don’t see very many hands being raised out there in Sage City. I didn’t raise my hand.
My recommendation is to set your module default date as soon as possible.
The other big issue is mismatching of document dates and transaction dates. Most of the time a document date and a transaction date should at least be in the same month or you will have problems reconciling to your general ledger.
Let’s discuss by module problems you may see with mismatched dates.
This is one of the most common date issues I run into with my clients.
If you do a payroll or a/p check dated December 30, but update the register with a January 3 date, you will have a bank reconciliation showing a different balance than the general ledger. Why? Because the bank reconciliation uses the check date for cutoff not the transaction date. Tom the auditor says “bad boy”. If you released the check on January 3, it should be posted to the general ledger on January 3.
Be especially careful when you reverse a previously entered check. Do change the check date to the general ledger period that the check is being reversed in.
On Sage City, a common question is, “Why doesn’t my aged invoice report match my general ledger, but the A/R Trial Balance report does?”
The A/R trial balance report should agree with the general leddger because it uses transaction dates. The aged invoice report has option “FUTURE TRANSACTIONS”. By default I believe it is set to EXCLUDE BY INVOICE DATE. To make sure you match the general ledger, use EXCLUDE BY TRANSACTION DATE.
If you A/R aging report (by invoice date) and A/R trial balance do not match it is a good idea to compare them and figure out which is more accurate. The error could be either in the document date or the transaction date.
Another less obvious place for error is in your A/R Sales Tax Report. It reports based on document date.
This is one of the few areas where I agree that you should be able to mismatch an invoice date with the general ledger transaction date. Sometimes you will get invoices from vendors that are for work done in a prior month, but they have dated the invoice in the current month. Correct accounting principles would have you accrue the invoice in the prior month, but you still want the accurate invoice date reflected for purposes of payment terms.
The A/P Aged Invoice Report works exclusively off of the invoice date so it is not a good report to tie to the general ledger. It does not have the same option as in receivables (but I wish it did).
You should use the A/P Trial Balance report to agree to the general ledger.
MY WISH LIST
An option in the various modules to prevent (or at a minimum warn of) mismatched document and transaction dates.
If you agree, you can vote for it at the ideas site: https://www5.v1ideas.com/TheSageGroupplc/Sage100ERP/Idea/Detail/27938.
Thanks for checking out my article. I hope you learned something that will make your job easier.
Thomas “TomTarget” Rogers Jr. Target System Technology, IncSOMETIMES THE BEST SOLUTION IS NOT OBTAINED BY ANSWERING THE QUESTION ASKED BUT IN UNDERSTANDING WHY THE QUESTION WAS ASKED