STARTING A NEW FISCAL/CALENDAR YEAR
If you use the full OSAS accounting system you will find it very easy to start a new fiscal/calendar year for your company if you follow these simple notes. If you only use the Payroll system, these notes do NOT apply to you. Whether your company starts a new year in January (calendar year), or if you start a new year in July or any other month (fiscal year), the procedure is the same. There is only one major rule to remember:
You can NOT enter or post any entries in any module (GL, AR, AP, PA, etc.) for the new year period 1 until you have created last-years data in the GL!
What this rule translates into in practical terms is that you usually want to perform the necessary “Create Last-Year Data” function in the GL in real-time. That is to say that you usually want to do it right at the actual calendar dates when the new period 1 is starting. Of course, your particular situation may be such that you can delay for a little while (perhaps because you don’t have a payroll due right away and you are not going to enter any AR or AP for the new year for a while), but there really is no reason to delay setting up for the new year since even after you create last-year data you can still enter data for either year. Remember the cardinal rule above. At some point relatively soon you are going to need to post some work to the new year period 1 so the create last-years data will need to be done.
The steps that need to be performed in order to be ready to start a new year are actually very easy. In fact, the time it takes to read these notes is longer than the time it takes to do the actual steps. I provide these notes for those who want to understand how it all works and to provide insight should something unexpected come up. The only steps you need to do in order to have the new year available are:
1. Post Accounts Payable so there is nothing in AP Daily Work.
2. Use the GL, Periodic Processing Menu, Create Last-Year Data
That’s it; within minutes you are ready for a new year.
The OSAS accounting system allows you to keep two fiscal years fully open at one time – this means any period in either of the two years. You can enter data, post, and print reports for either the current year or last year for as long as you wish. When you move the year you are now ending into “Last-Year” you really don’t loose anything. You can still make entries, post, and do all your reports as needed. It just means that everyone who works on the system needs to know which year is current and which one is last-year.
Of course, you do lose one thing. When you move the year you are ending into the LAST-YEAR spot, then the year that was in last-year will not be accessible from AR and AP. This is not a concern because that year is by now 11-12 months old, and there is no reason to enter things to that year through AR and AP.
In the GL you always have access to any past year you have done on the system (assuming you have not chosen to deleted it). In the GL you can always make entries, Post to Master, and print reports for ANY year you desire with no limit. In the other accounting modules (AR, AP, PA, etc.) you can only make entries and post to either the “current” or “last” year. This is really not a limitation, since there would never be a good reason to make AR or AP entries to a year that is more than one year old and thus unreachable through the last-year files.
While a good operator is in the habit of performing month-end maintenance in each of the accounting modules, whether you have been good about doing your regular maintenance or not, it really has no bearing on the year-end procedure. Keep in mind that in OSAS you never need to officially close a period (or a year). At some point you simply stop making entries and consider the period done, but that doesn’t mean that OSAS would not let you make more entries if you wanted to. Of course that would change the reports you have already printed – so it may not be desirable. The important point to take from this is that any monthly/quarterly maintenance you do in AR and AP really has no significant effect on your accounting system other than the obvious housekeeping it does when you purge data and reset counters that tract monthly sales/purchases etc.
Dates are only significant in determining the PERIOD the entry goes to. Dates, and the year within the date have NO effect on which year your entry ends up in. It is not really practical for the system to force an entry into a fiscal year based on the date. Know that it is solely the operator’s choice as to which year to post to that determines the year the entry ends up in. When you are actively working on two years it is usually a good rule that all period 1 is going to the “current” year, and period 12 is going to “Last” year.
By design, whenever you start-up and come into OSAS, you are always in the current year. So if you exit out of OSAS and come back in, it doesn’t matter what year you were working on the last time, the default is always to start in the current year.
At the GL menu, you may use the F9 key to select a different year or to return to the current year. In the GL, once you change years (notice that the year you are in is shown on the GL menu) you can do anything you want within the GL menu system for the year you are in. Note that the F9 key to select the year is only used in the GL and Payroll menus. None of the other applications recognize the F9 key, and pressing F9 while in GL does NOT switch your payroll year or vice-versa.
The AR system has only one process that interfaces with the GL. That is the POST TRANSACTIONS found at the bottom of the Transaction Reports menu. In AR when you do the POST, you may choose which year to post to: 1: Current Year or 2: Last Year. This is what determines which year the postings go to. It doesn’t matter what date the transactions have, or the date on your computer. They will go into the GL journal file for the year you select on this screen. It also doesn’t matter what year you may have set in the GL. Selecting a year in the GL has no effect on any of the other modules.
As you can tell, since you must select EITHER the current or last year when posting, all the postings are going to go to the selected year. This means that you would not want to have transactions for periods 12 and 1 in the same batch or group of entries to post. Segregate your work by year before you enter it. Post all of one batch of work to the desired year, and you can turn around and enter and post the next batch to whichever year you want. So you can still work in both years, you simply need to post the work separately. This same idea pertains to AP as well.
The AP system has two processes that interface with the GL: POST TRANSACTIONS found at the bottom of the Daily Work menu, and POST PAYMENTS found on the Pay Invoices menu. AP is different from the AR side in that for the purchase transactions you are entering, you are asked to select which year you want them to go to BEFORE you enter them. This is very different from the AR side where you choose when you post them. So for AP, when you begin your Daily Work – Transactions, if the transaction file is empty, the system will prompt you to choose which year current or last you want these entries to go to. The default is 1 for current year. You need to pay particular attention to this prompt if you are entering a group of transactions for last year (because the default is current year). For most of the year the operator is accustomed to simply pressing <enter> at this prompt and it is easy to get past this selection without even knowing what you have done. You are only asked to make this declaration if the transaction file is empty. Once made, all entries in that batch are going to be posted together.
If you have a group of transactions that have been entered in AP for period 12 of LAST YEAR, but you failed to select last-year when you started the entry, you will be in a pickle when you come to post the transactions. The post screen shows the selection you made when you started the entries for the current or last year, but you cannot change the selection on this screen. If you find yourself in this pickle, it will be helpful to know that in File Maintenance, Tables, you will find a table by the name of TLASTxxx (where the xxx is your company ID). This table has a single digit. If the digit is 0, then the transactions are going to post to the current year. If the digit is 1, the transactions will be posted to last-year. You may force this table to be what you want it to be if you find you made the wrong choice when you began data entry.
The POST PAYMENTS screen in AP is straightforward. You may select the current or last year as desired. This selection for posting the payments is made based on the check date. It doesn’t matter what year the expenses you are paying were for, it only matters when you are paying them – in the current or last year based on the date of the checks.
Payroll has two posts that interface with the GL: POST CHECKS, and POST EXPENSE TO GL. The PA side is simple like the AR side; you get to pick which year to post to right on each of the post screens. (If you do not have the interface active between payroll and the GL, you do not need to be concerned with this part of it.)
Unless you are running a special manual checks run, the Post Checks will almost always go to the current year. It works out this way mainly because the period and year for the post checks is always answered based on the check date. Payroll is normally done in close to “real time”, meaning the date on the checks is usually very close to today’s date or maybe a few days in the future. Of course, you sometimes need to make special adjustments etc. in payroll, so you may find that you have an occasion to post checks to last year, but this will be relatively uncommon.
The Post Expense to GL screen will also allow you to select the year. It is not uncommon at all for the first payroll of the new year to be posted to last year.
Remember the two posts in Payroll are independent of each other. In payroll you will almost always be selecting to post to the current year in both post screens. However, it is not uncommon on the first payroll of the new year to post the expense to last year. The only other time you may find yourself posting payroll to last year is when you have special manual check adjustments that you have to make right around the beginning of the new year.
Many companies run staff payrolls in a different company from the rest of the accounting, then they transfer the postings from staff payroll into the main accounting company. If you use this transfer, it is important for you to perform the Create Last-Year Data in the GL for the staff company at the same time you do it for the main company. This keeps both GL systems in agreement about what is the current and what is the last-year.
Wow! That’s a lot of background and details for a simple process! But the above information is very good stuff to understand if your job is to run the system on a day-to-day, year-to-year basis. Knowing the above information will help you avoid some time consuming mistakes, but the nice thing about an accounting system is you can always make an adjusting entry. I’m all for avoiding problems to begin with so a lot of adjusting entries aren’t necessary.
The simple process that gets you all ready for a new year in your accounting system is found in the General Ledger, under Periodic Processing, and it is CREATE LAST-YEAR DATA.
There is only one requirement before you do this step – AP Daily Work should be posted. While it’s a good idea to have both AR and AP posted in daily work it is most important that AP be posted. The reason is because of the way the selection of the year is done in AP. In AP you choose the year before you begin your entries. If you have work already in process in daily work in AP, it is very likely that it is for period 12. The default selection when you began entry was to select the CURRENT year, which means the entries that are in process in AP are probably marked for period 12 of the current year. That was fine and good when you started the entries, but here we are about to change what the current year is. If we don’t post the AP now, they will want to post to period 12 of the wrong year after we do this process.
If you have any prepaid checks in AP, you will also want to prepare checks and post the payments in order to force those prepaid checks into the correct year.
It is a simple, single requirement – make sure AP is posted. I do think it is a good idea to have AR posted as well. While not required, it gives you a clear line so there is no confusion as to what year you want to post a given batch of entries.
*- 2001 ------------------- Create Last-Year Data ----------------------------*
| Have You Backed Up Your Current-Year Files? |
| Reset Current-Year Journal Entry Number to 1? |
| Retained Earnings Account For Company 1 ? |
| Copy Next-Year Budget to Current-Year Budget? |
| Do You Want to Zero Next-Year Budget Balances? |
*- Company 1 -------------------------------------------------------- Verify -*
Have You Backed Up Your Current-Year Files?
You must say yes in order to continue. I do not recommend any special backup for this purpose. I assume your system is already being backed up on a regular basis.
Reset Current-Year Journal Entry Number to 1?
I would always say YES. As you post or enter GL Journal entries, they are automatically assigned a sequential entry number by the program. The system is just asking whether or not you want this number to start at 1 for the new year. I can think of no reason not to.
Retained Earnings Account for Company XXX?
This is the closing account you would use to close all revenue and expenses to at the end of the year. This account would usually be a fund balance account or retained earnings account found on the liability or equity side of your ledger. You probably have this account already in each revenue and expense account as the closing account.
Copy Next-Year Budget to Current-Year Budget?
This pertains to the new year chart of accounts. Some companies get a jump on entering the next year budget into the chart prior to the end of the year. The system allows you to do this and not effect the current year budget as you work by having a special place called next-year budget. (You would see this in the screen where you enter your budget.)
If you have used the next-year budget fields and wish to now move them into the current-year budget spot for the new year then say YES to this question. If you have not entered figures into the NEXT-YEAR budget spot, then you would say NO.
Do You Want to Zero Next-Year Budget Balances?
This questions is somewhat related to the question above. If you used the next-year budget spot, you will be moving them into the current spot. This question then allows you to zero the next-year budget spots after they have been moved. If you said YES to the previous questions, you probably want to say YES to this question. You may also want to say YES to this question just to make sure that the NEXT-YEAR budget spots are all zero in the new chart of accounts.
After you answer the above questions, the system will ask you for an output selection. The report that it wants to print has one line for each account in your chart. This can be a long report if you have a large chart of accounts. Frankly, I have no use for this report. Bottom line – it is meaningless. What it represents is the balance that is in the accounts as you perform this task. But the reality is that your data is being saved anyway, so if you wanted to get those balances, you could always print a report even after all of this work is completed. Secondly, it is very likely you will have more work to do in the prior year after this task is completed – so what do the present balances mean anyway? Nothing!
For the output selection, I like to use a file. I use a file because if you ever dreamed up a need for the figures they would be in this file, but more importantly, it makes the whole process move much faster. Choose a file, and give it a name something like: GLCLOSE.TXT (overwrite if it already exists)
When the process is finished, the system will return to the menu and you will officially be in the new current year. What the system has done is moved what was your current year chart of accounts and journal file into the last-year. It has given you a fresh chart of accounts with the balance sheet accounts having beginning balances right where they left off and the revenue and expense accounts are all starting with zero. In the new chart of accounts, the columns for LAST YEAR now contain history figures from the year that is now last-year. The GL Journal file is empty and waiting for entry number 1 to be posted.
After you have created your last-year data files. You are now free to make entries to either the new current year, or the last-year. All that is necessary is to keep in mind the issues that pertain to posting to current year or last-year from each module as described earlier.
When you are in the subsidiary modules of AR, AP, and PA, you always choose 1 for the current year, and 2 for last-year. Each module will display the number for the year, i.e. 2002, 2001, etc. next to the descriptive label current or last-year. The actually number that you see with the label current or last-year should be accurate. In other words, what it says is your current year, i.e. 2002, should really be your current year. And what it describes as last-year really should be the correct last-year number.
This wasn’t always the way it worked. It use to be a concern that these numbers would not be correct unless we modified a table file in AR (ARPDx) and AP (APPDx). You should not need to do anything else, and the correct year numbers should appear as you post from any module.
Remember that the system allows you to keep two years going at one time for up to a year, then the only year you lose access to from AR and AP is the year that is already a year old by then. So simply by performing the create last-year function, answering a few simple questions, you have access to the two years you care most about for up to 12 more months.
There is really only one hang-up. What about the fact that you are still making entries to last-year and thus changing balances in last-year? What effect does this have on the current year? That is a good question. And the system has a good answer.
Update Current Year
Back in GL, Periodic Processing, there is another function: Update Current Year. This function can be run as many times as you wish, and whenever you wish. There is no downside or harm in doing it, and the program is smart enough to only allow you to run this program if you are in last-year. What it does is to update the beginning balances on your balance sheet for the current year with what are now the ending balances in the last-year. This is desirable if you wish to produce an accurate balance sheet for the current year. It also copies the last-year ACTUAL period totals into the last-year spot in the chart for the current year. So this function will never do any harm. If nothing has changed in last-year, the information it copies is the same as it would have copied the last time. However, if you did make changes in last-year, the changes will then be reflected in the current year where they need to be. If in doubt, do it. The process asks for your retained earnings account, and give the same account you used when you did the create last-year function.
The danger in not using the update function is that your balance sheet in the new year will not reflect the correct beginning balances. Not the end of the world, but it can be confusing when trying to reconcile your statements.
On the periodic processing menu in GL is an option for Clear and Close Last Year. I cannot think of any reason to ever run this option. (This option has been in the software for many years, and back in the old days when the design was very different, this was useful – but not anymore.)
In the GL Periodic Processing menu there are also options to do Month-End Maintenance, Consolidate Master Files, and Remove Prior-Year Files. None of these options have any useful function for most companies. The only two functions you should ever need to use in the GL Periodic Processing menu are the two described above:
-Create Last-Year Data
-Update Current Year
The most important thing to know is that there is not a single thing that must be done at a critical time in AR and AP. You can do your maintenance in AR and AP whenever you want. It really doesn’t make much difference.
The reason it doesn’t matter is that many companies process data in AR and AP for both the current and the last year in an overlapping fashion for some time. It usually is only a matter of weeks (or days), but for many companies there is no clear-cut day where everything then switches over from one year to the next.
If your company is one that does impose a clear cut-off line and you do not enter anything for the new year until you have finished the last-year, then by all means take advantage of that situation and perform your year-end maintenance in AR and AP at the cutoff time.
If your company overlaps years and keeps both active for a while, then pick any time you like to do the year-end maintenance in AR and AP.
Year-End in AR and AP only effects certain counters or “holding pots”. For example, in AR there are fields on the customer’s history information screen that pertain to Period-To-Date, Qtr-To-Date, Year-To-Date, and Last-Year. In AP, each vendor has similar history field holding pots. Your performance of year-end maintenance will effect these fields, but these are not critical fields of data. More important is the fact that if you overlap years, there really is no clean cutoff date that would make these fields more accurate one way or the other.
So don’t worry, do it when you want. The only serious issue pertains to the printing of 1099s for your vendors who need one from AP. There is a holding pot that can be found on the vendor’s history screen that keeps the figure used to print the 1099. I don’t consider this a serious issue. What I recommend is using a payments history report from AP to verify exactly what you have paid any vendor you need to print a 1099 for. Having established what the figure should be from the payments history, you can plug this figure into the spot in the vendor’s history screen so it will appear on the 1099. I like this approach because it eliminates all the issues about “How did the figure that is in there, get there?” There is no more precise way to validate amounts for your 1099s than to use the payments history report and select the calendar year you desire for the report period. You also then have the documentation for the figures you use on the 1099s. They just don’t appear from some holding pot.
Some users may discover that the year and/or period are wrong when they go into their periodic maintenance in AR and AP. A helpful thing to know is that in AR the table ARPDx (x is your company ID) holds what the system believes to be your current period and year. In AP the table is APPDx. You may change these tables at any time to make them reflect what is accurate for where you are at in your processing. These tables will drift off if you have not done regular periodic processing. There really is no significant issue with changing these tables at any time you discover them to be inaccurate.