Parameter Settings > General Ledger Tab
These parameters pertain to the General Ledger application. Some fields are only accessible during initial set up and should not be modified later.
Non-standard GL Somewhat different information is displayed when a company is using "non-standard" GL. Non-standard GL provides the ability for a company to customize the dates of ledger cycles and number of cycles (12 or 13 regular cycles, plus one additional "adjustment" cycle). To enable "non-standard" GL, your company must not already have posted any journal entries using the "standard" monthly cycle method. Given this, this option is only available for sites (companies) who are using the ledger for the first time (new users primarily). The reason for using this feature would be to create comparable ledger cycles (cycles of equal length in days or business days, etc.). Calendar-based cycles vary in length and the number of actual business days vs. weekends, etc. aren't consistent. For this reason, comparing financial activity one monthly cycle to another isn't completely equivalent.
Cycle Count The number of standard cycles to use. A value of either 12 or 13 is allowed. A final and additional "adjustment" cycle is always added automatically. The adjustment cycle is not date-based and is used for year-end adjustments, etc. FYR The fiscal year that the cycle dates are being set for. Processing involves saving dates for one year at-a-time beginning with the earliest year and moving forward. Start (Date) The starting date of the fiscal year. This is the same as the first cycle's start date which is disabled. Date and Name (Columns) Enter the starting dates for each cycle period. The "name" in the right-hand column is what will display for the cycle period "name" in areas where cycle names are provided for selection or display. These will replace the standard "monthly" names found in other areas of the software (January, February, etc.). The name columns default to the numeric month-day (MM-DD) of the start date of the cycle. These can be modified to other values if preferred. End (Date) The last day of the fiscal year (typically, the following year will start on the next day). Skipping or excluding days between years may cause issues if, for any reason, activity occurs on those dates. Save This saves the settings for the selected fiscal year. Changes to a year in progress, dates, etc., won't be applied retroactively to any existing journals. |
Fiscal Year Start
This is the first month or cycle name of your company's fiscal (financial) year.
Current Cycle
This is the current (oldest open) cycle of the current fiscal year.
Current FYR (Fiscal Year)
This is the current (oldest open) fiscal year. Closing the last open cycle of the current fiscal year, closes that year.
Name on Financials
Sometimes a business files taxes under a particular business name but operates using another. This field is for specifying the name that should be printed on your company's financial statements when processed in the application. If nothing is entered here, no company name is printed. Changes can be made to this field at any time.
Auto Post Journals
If enabled, daily system journals are immediately marked as “selected” for posting as soon as they are created. After the journals have created for the day, ALL selected journals are posted. This includes any journals that had been manually selected in addition to those created by daily (EOD) processing. Although this may seem convenient, it can make corrections more difficult especially if a problem is not noticed immediately. It’s is strongly suggested that journal entries be reviewed on a regular, if not daily, basis. It is also possible to split retained earnings (equity) and net income account entries by branch for the EOD auto-post option.
Restrict User Depts Current Branch
If checked, users will only be able to select ledger accounts with a department matching their session's current branch. If they are allowed and change branches, the selections would change accordingly.
Restrict User Depts Allowed Branches
If checked, users will only be able to select ledger accounts where the department matches any of their allowed branches, but not necessarily their current branch (unless the "Restrict User Depts Current Branch" parameter is also checked).
Branch Retained Earnings - Income/Expense Only
When you select this check box, you prevent the business’s retained earnings from being affected when the branch earnings change, but the overall retained earnings have not changed. The application suppresses the retained earnings entries from journals that contain only assets, liabilities, and equity-type accounts.
Cycles
With standard GL, there are thirteen (13) cycles in a fiscal year. Non-standard GL (optional for new customers) allows either thirteen (13) or fourteen (14) when you include the final "adjustment" cycle.
"Standard" general ledger cycles exists for each month plus one additional cycle for the purpose of adjustments. Cycle 01 should be the month that your company's fiscal year begins, and cycle 12 should be the last month in your company's fiscal year. If your company's fiscal year is the same as the calendar year, cycle "01" would be January and cycle "12," December, for example.
Non-standard ledger cycles can be either 12 or 13 periods plus an additional adjustment cycle (for a total of either 13 or 14 cycles). The names of these cycles can be determined by your company.
Account Structure
There are four (4) choices for account number format. The format can be changed later, but only if the change is to a longer account number format (one with more digits). There is no option for changing from an account format with more digits to one with less. The maximum length for an account number is 15-digits using a print format of #####-####-###-### (5-4-3-3). Minimally, ledger accounts can be 5-digits (#####) as a single set of numbers.
For companies with more than one location, the minimal format is usually not sufficient because no department exists (department is the second set of numbers). These businesses should choose a format that includes a department number.
From left-to-right, the first set of 5-digits is the primary account number (12345-1010-000-001). The primary account determines the location of where the account is listed in your chart of account and on financial statements as well as the type of account (asset, liability, etc.) which are defined as numeric ranges.
The second set of digits (if enabled) is the department code (12345-1010-000-001). For multi-branch locations, this can be used to designate a branch. The "branch department offsets" section allows an offset (or bias) number to be assigned to branches. Department codes will be created by taking the "bias" figure and adding that to any "base" department codes which have been designated (also on this Parameter tab).
In addition to the main account and departments, users can select longer account formats offering either one (1) or two (2) additional sets of 3-digits offering a larger potential number of account levels.
Base and Offsets with Branch Departments
Three of the four (4) account numbering formats offer a department code. This is a 4-digit segment of numbers (second from the right) in a ledger account. The most common use of the department section is for indicating accounts used by branch locations (departments may also be used for other purposes as well).
We offer a "Setup Branch Accounts" utility (General Ledger, Utilities). This utility creates new "branch" ledger accounts using the Base Department Offsets and Base Department Codes defined in Parameters. The benefit to the utility is that it offers an easy way to generate accounts when a department is added (or during initial ledger setup) from your existing base-department accounts. When processing, the utility searches the existing Chart of Accounts for posting-type "base" accounts enabled for "branch" mapping and creates branch accounts in those cases. Ledger accounts can be set to use branch mapping from either the System Journal or Detail Mapping Database forms. Unless the mapping specifies that the mapping option should use branch accounts, the base account is used instead (this is done even if you've added the same account with "branch" departments).
Parameters determine two (2) things regarding department codes: (1) the number sequence used to identify any "base" departments and (2) the offsets applied to base departments that are used to identify a branch location. Base departments specify the department codes used for general accounts (zero would be a department code that appears as "0000"). Branch offsets determine the department codes for when branch accounts are used with an account matching any accounts matching one of the "BASE" departments listed.
Usually, there is one (1) BASE department code with the "branch" check box checked (also, most of the time the "base" department number is zero). This should be set first and saved (using Process (F12)) before adding any branch offsets or other departments.
Example #1 (Suggested)
The following example displays our suggested department offset scheme for a company with numeric branch identifiers. This sets the department code for ledger accounts to be identical to the branch ID shown in the software. Please note a single base department of zero (0) is used. Any additional non-branch departments (departments that are not location specific) you need can be specified under the Base Department Codes data grid, but you should not check the branch check box in those cases.
Using the simple example shown above, our single base department code is 0 ("0000") and the "Branch" check box is checked, so each branch's offset would be added to the base (bias) department to determine (calculate) that branch's department code:
Branch ID |
Name |
Bias (Offset) |
Base Department Code |
Resulting Department |
---|---|---|---|---|
1000 |
West Location |
1000 |
0 |
1000 |
2000 |
East Location |
2000 |
0 |
2000 |
3000 |
North Location |
3000 |
0 |
3000 |
4000 |
South Location |
4000 |
0 |
4000 |
*For example, if a base department account of 12000-0000-000-000 was mapped to a system journal and the "branch" check box selected, the process creating journal entries would look for an account numbered 12000-1000-000-000 for recording branch 1000's activity.
Example #2
This can get trickier, however. Your company can choose any base (bias) and any offset. Here's an example of how using a base department code of 1000 (instead of zero) and bias offsets of single digits:
Branch ID |
Name |
Bias (Offset) |
Base Department Code |
Resulting Department |
---|---|---|---|---|
1000 |
West Location |
1 |
1000 |
1001 |
2000 |
East Location |
2 |
1000 |
1002 |
3000 |
North Location |
3 |
1000 |
1003 |
4000 |
South Location |
4 |
1000 |
1004 |
*For example, if a base department account of 12000-1000-000-000 was mapped to a system journal and the "branch" check box selected, the process creating journal entries would look for an account numbered 12000-1001-000-000 for recording branch 1000's activity.
Example #3
If you were to define an additional base department that also has the "branch" check box checked, it would result in more than one valid department value per branch.
Branch ID |
Name |
Bias (Offset) |
Base Department Codes |
Resulting Departments |
---|---|---|---|---|
1000 |
West Location |
1000 |
0,1 |
1000,1001 |
2000 |
East Location |
2000 |
0,1 |
2000,2001 |
3000 |
North Location |
3000 |
0,1 |
3000,3001 |
4000 |
South Location |
4000 |
0,1 |
4000,4001 |
*For example, if a base department account of 12000-0000-000-000 was mapped to a system journal and the "branch" check box selected, the process creating journal entries would look for an account numbered 12000-1000-000-000 for recording branch 1000's activity. Additionally, any mapping for a base account of 12000-0001-000-000 with the "branch" check box checked would look for a "branch" account of 12000-1001-000-000. Both would be considered branch 1000's activity.
Example #4
Here's another example, using a single base department of zero but a bias (offset) using hundreds:
Branch ID |
Name |
Bias (Offset) |
Base Department Code |
Resulting Department |
---|---|---|---|---|
1000 |
West Location |
100 |
0 |
0100 |
2000 |
East Location |
200 |
0 |
0200 |
3000 |
North Location |
300 |
0 |
0300 |
4000 |
South Location |
400 |
0 |
0400 |
*For example, if a base department account of 12000-0000-000-000 was mapped to a system journal and the "branch" check box selected, the process creating journal entries would look for an account numbered 12000-0100-000-000 for recording branch 1000's activity.
Other Considerations - Situations
There are a few other considerations as well. For instance, your company's branch ID scheme may not be numbers, it could be letters such as "ABCD." In this case, you'd need to determine what numbers make sense.
You can also define "base" departments that aren't "branch" specific. In these cases, you wouldn't check the "Branch" check box for the base department code.