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.

Main Menu > Maintenance > Database > Parameters, General Ledger

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.

We suggest that companies using this feature, save dates for many fiscal years ahead to prevent issues should this be forgotten at a later time. It is your company's responsibility to maintain any non-standard ledger cycle information going forward. Existing year data does not automatically roll forward should your company forget to assign dates, etc.

If prior to enabling Non-standard GL, the fiscal year start, current cycle, and cycle name parameters have already been set, they will need to be cleared (deleted) prior to saving the "non-standard" cycles and fiscal year information. After saving the non-standard cycle information, set the "fiscal year start" and "current cycle" accordingly (the "names" assigned should be listed for selection).

Non-standard GL can only be enabled if absolutely no posting (finalization) of journals has been done!

Main Menu > Maintenance > Database > Parameters, General Ledger

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.

GL_Account_Structure_Diagram

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).

Journal_BaseOffset

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.

Parameters_GL_Base_Departments

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:

Parameters_GL_Base_Dept_Ex2

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.

Parameters_GL_Base_Dept_Ex3

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:

Parameters_GL_Base_Dept_Ex4

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.

Parameters_GL_Base_Dept_Ex5