Priority’s general ledger provides full multi-year account maintenance, enabling you to perform reconciliations and queries and generate financial statements for transactions covering more than one fiscal year. Moreover, you can record transactions for a new year without having to close the old one. When transactions from previous fiscal years are recorded, the opening balance of the current year is automatically updated.


One of the most important tools available when working with an account ledger is the Audit Trail. This tool makes it possible to move, with the touch of a key, from any transaction recorded in the account to the original transaction document (invoice, receipt, payment, deposit). This feature is a concrete expression of the overall integrative nature of the Financials module (specifically the general ledger) with the rest of the system.

In the dual-currency package, Priority records each transaction in two currencies (local and second) according to their exchange rate at the moment the transaction is recorded. This feature enables the production of reports in two currencies for the sake of comparison, without the need to carry out additional price adjustments.

In addition, any foreign currency account can be maintained in yet another currency. All transaction values are then recorded in the appropriate account currency.

It is possible to maintain up to fifteen fiscal periods in each fiscal year. The system automatically defines twelve periods (one per calendar month), which may be revised. Additional periods are defined according to user requirements. Each period must be opened before transactions can be recorded for it and is closed when transaction recording is completed (although it can be reopened). This helps prevent the posting of entries to the wrong period.

You can close a fiscal period by transaction date, by reference date, or by both. If you close a period by reference date, no further journal entries can be posted whose reference date falls within that period. If you close the period by transaction date, no further journal entries can be posted whose transaction date falls within that period.

In the dual-currency package, maintenance of price index values allows for the production of indexed reports and the indexing of transactions.

Chart of Accounts

Priority’s accounts are maintained in three separate charts of accounts: the main Chart of Accounts (for general ledger accounts), the Chart of Accounts Receivable (for customer accounts) and the Chart of Accounts Payable (for vendor accounts).

For each account, it is possible to view, among other things, the following information:

 The current balance in the account currency (in the dual-currency package, account balances are also displayed in the designated second currency).

 Ledger transactions for the current year and for multiple years.

 Monthly balances for the current year and for multiple years.

 Cumulative balances, which are recalculated automatically when the user re-sorts the displayed record order.

 Unreconciled transactions in the account.

General Ledger Accounts

All income, expense and balance sheet accounts appear in the Chart of Accounts, except for customer and vendor accounts (which are maintained in subsidiary charts of accounts). All accounts appearing in this form are considered general ledger (GL) accounts.

When setting up the system you can run an account initialization program that automatically opens GL accounts based on a list of predefined accounts.

You can define specific accounts as secured, so that only those users who have received authorization in their Personnel File can view them.

Multi-Company Enterprises 

When working in a multi-company enterprise you can designate transfer accounts in the Chart of Accounts. This enables the automatic transfer of transactions between branch and parent companies and generates parallel recording of entries in both companies’ ledgers.

Transfer accounts can also be used when you want to distribute expenses over two or more branch companies. You can record expenses in one company and then transfer a portion of those expenses to another. For example, payment of a bill at the branch company will automatically debit an expense account of the parent company.

Priority can automatically update exchange rates in all companies comprising the multi-company enterprise. Any rates specified in one company are automatically copied into the others. Moreover, consolidated financial statements, including aging and customer credit reports, can be produced for such enterprises.

Chart of Accounts – A/R and A/P 

All customer and vendor accounts are designated in the Chart of Accounts Receivable or Chart of Accounts Payable, respectively.

Customer accounts are normally opened beforehand through the Marketing and Sales module. When a potential customer is converted to a regular customer, an account is opened automatically (accounts are not maintained in the Financials module for potential customers). If a customer account is first opened in the Chart of Accounts Receivable, a customer record is opened automatically in the Marketing and Sales module.

When a vendor record is added to the Purchasing module, an account is automatically opened in the Chart of Accounts Payable.

Exchange Rate Adjustments 

If you work with foreign currency accounts, fluctuations in exchange rates need to be taken into account periodically in order to produce more accurate financial statements. This is accomplished by journal entries, created automatically, which adjust account balances compensating for the varying exchange rates. Adjustment entries are generally recorded against a default adjustment account. However, individual contra accounts can be designated for specific foreign currency accounts.

Index Linkage (dual-currency package) 

Linkages to a price index are carried out for accounts that have been flagged as indexed accounts. The type of indexing that is used with each account is determined by its balance sheet item. Depreciation transactions are indexed according to the base value of the index on the day the asset was purchased.

Auxiliary Financial Programs 

Combining Accounts: allows two GL accounts to be merged (e.g., when two accounts were accidentally opened for the same purpose).

Transferring Prepaid Expenses: a mechanism for distributing expenses paid out in one lump sum (e.g., insurance) over the course of the fiscal year. This is achieved by creating an interim account that holds the unused portion of the expense. As the year progresses, sums are gradually transferred from this account to an expense account.

Cash Postdated Checks: in the dual-currency package, a mechanism for dealing with post-dated payments from customers, by recording journal entries that transfer balances from post-dated check accounts to the main GL account for each bank.

Entry Journal 

Priority’s Entry Journal provides convenient and efficient maintenance of entries (pending, posted and provisional), as well as on-the-spot traceability to the original financial transaction (e.g., receipt, invoice, credit memo). With the touch of a button from the Reference column of the entry, you are able to access the type of financial document in question and open the appropriate form (dynamic form activation).

Three distinct dates may be maintained for each entry:

 A transaction date (determining the fiscal period to which the transaction belongs)

 A due date (e.g., payment date)

 A reference date (the original date on which the transaction was recorded).

This distinction is particularly useful when the reference date differs from the transaction date, such as in a vendor invoice that was received late. In addition, the system automatically records the last date the transaction was revised (time stamp).

Batch Entries

The system supports the management of journal entries in batches. Working in batches is particularly convenient for businesses in which different users are responsible for recording different types of journal entries (for example, one user handles salaries, another purchasing and a third expenses). Batches are created and closed automatically by means of programs designed for this purpose. In addition, you can use a separate form to review and revise batch entries. The system provides two options for posting a batch of entries to the ledger: the first posts all entries included in the chosen batch, while the second posts all selected entries, even if they belong to different batches or do not belong to any batch.

Recording Journal Entries 

Every financial transaction (e.g., sales invoice, receipt), once finalized, automatically opens a journal entry for the monetary amount of the transaction. Furthermore, the entry is itemized automatically. That is, the entry sum is broken down into amounts that are to be debited and credited to various accounts, without any limit to the number of entry lines. There is also an option for recording journal entries manually.

Priority maintains pending journal entries, which are assigned a temporary number (T1, T2, …, T100, …) until they are posted. This number allows for easy identification and separate handling, as pending and posted entries are recorded and reviewed in the same form. Once the entry is posted to the ledger, the accounts in question are credited or debited, and the entry is assigned a unique final number.

The system offers three methods for posting journal entries, among which the user can choose the one best suited for the organization’s needs:

Posting single entries

Posting a batch of entries together

Automatically posting entries as they are opened, i.e., when the original financial document is finalized (this option only applies to journal entries created on the basis of a financial document).

The process of posting includes checks to ensure that the journal entry meets the following conditions:

It is itemized.

The sum of the credits and debits equals the total sum of the transaction.

The transaction date falls within an open fiscal period.

The entry is not undergoing checks.

The sum of the entry is not zero.

The system allows for certain minor revisions in posted entries (e.g., transaction date, reference), along with documentation of the change.

A mechanism is also available for reversing posted entries, activated by a single keystroke. A reversing journal entry is automatically recorded with the same reference number as the original entry.

Journal Entry Types

Priority maintains journal entry codes that determine the accounts that are to be debited and credited in a given type of entry. For example, a sales invoice to a customer who pays tax will: 1) debit the customer’s account; 2) credit the sales tax account; 3) credit the appropriate income account. (Note that income accounts can be designated per sold item or group of items.)

You can also define journal types that allow the entry of negative sums (e.g., to record a credit or debit memo).

The system provides a list of predefined entry codes for each standard financial document. In some cases, the manner in which the entry is constructed may be modified. Moreover, completely new entry codes may be defined to meet the specific needs of the organization. There is no limit to the number of accounts that may be credited or debited in any one journal-entry code. For example, a special journal entry code may be created for recording property or municipal taxes, which distributes the debit amongst the company’s various departments.

Every type of financial transaction is assigned a default journal entry code that may be revised at the time the document is recorded. In the case of a manual entry, the code may be selected as the entry is recorded.

Provisional Entries 

You can record entries for anticipated transactions that are unrelated to a specific order or invoice (e.g., salaries, loan repayments), as well as for forecasted or fictitious transactions. These transactions can then be included in the various cash flow forecast reports without affecting account balances or the general ledger.

Provisional entries receive a unique number prefixed with the letter “A”. They are maintained in the same form as regular journal entries, where they can be retrieved and viewed. Subsequently, provisional entries can either be converted to regular journal entries and posted to the ledger, or deleted.

The Create Provisional Entries program allows data from sales, purchasing and inventory transactions to be incorporated into cash flow forecasts. The program enables the automatic creation of provisional journal entries based on: open sales orders, unbilled customer shipments; open purchase orders and/or unbilled goods receiving vouchers.

Connection to Financial Documents 

When working with the Entry Journal, you can take advantage of one of the more advanced features of the system: dynamic form activation. This utility enables you to drill down directly from a record displayed in one form to another containing information relevant to that record. For example, while viewing a journal entry based on a sales invoice, it is possible, with the touch of a button (from the Reference column), to open the invoice on which it is based. The system identifies the type of transaction in question and opens the appropriate form. This drill down feature allows you to view and further research the source of the journal entry.


Priority supports both reconciliations within accounts (between debit and credit entries) and reconciliations of bank and credit card statements with journal entries. In both cases, reconciliations can be carried out automatically (according to user-defined reconciliation methods) or manually. Automatic reconciliations are considered pending until the user authorizes them. Manual reconciliations are carried out with the help of a worksheet.

Reconciliation Methods and Codes 

Automatic reconciliation matches entries using a set of reconciliation methods (e.g., by reference number, details, sum), which are defined within a reconciliation code. The reconciliation method determines the basis of comparison; the code defines the sequence in which comparisons are made. A default code, made up of a predefined set of methods, is provided for each type of reconciliation (account, bank/credit card); however, you can revise the defaults and construct new codes of your own.

When constructing or updating a reconciliation code, you can specify:

What should be compared (amount, reference)

The permitted range in days (over which to compare due dates)

A restriction on the number of characters to compare(e.g., only the last five characters of the reference)

Permitted variance between the sums of two or more items

A limit on the number of items being reconciled with one another (i.e. one bank statement item with one journal entry item)

Whether or no the items must be on different sides of the balance sheet (one credit with one debit).

Take, for example, the method designed for the system’s default reconciliation code for bank statements:

1. Match Reference 1 (e.g., the check number in the statement) with Reference 2 (e.g., the check number for the entry) for the same date.

2. Match Reference 1 with Reference 2 up to a difference of two days.

3. Compare by details.

4. Compare amounts only for the same date.

5. Compare amounts only up to a difference of one day.

6. Compare amounts only up to a difference of two days.

Reconciliation Worksheet 

All reconciliations — whether automatic or manual, for accounts or for bank/credit card statements — are carried out with the aid of a worksheet. Once the worksheet is prepared with a set of unreconciled items (by means of a program), you can activate automatic reconciliation, view results in the worksheet and make any necessary corrections or additions. Until results are authorized, the reconciliations will be considered pending.

Account Reconciliation 

Account reconciliation is carried out with the aid of a worksheet, which displays all unreconciled journal entries for the designated account. Reconciliation can also be carried out for several accounts simultaneously.

Once the worksheet is prepared with a set of unreconciled items, you can activate automatic reconciliation. The system will reconcile entries according to the selected reconciliation methods. Results can be viewed in the worksheet, and any necessary corrections or additions can be made there. Until results are authorized, the reconciliations will be considered pending.

Alternatively, you can enter the worksheet and reconcile amounts manually. Here, too, reconciliations are not considered final until they are authorized.

Additional features:

Two or more entry items may be reconciled even if their amounts are not identical. A small variance (e.g., one cent) may be permitted.

When reconciling matching entries that do not balance (e.g. when writing off underpayment of an invoice), the variance can be written to a special adjustment account. Once the reconciliation is finalized, an adjusting entry will be posted against that account.

Multiple entries can be reconciled together.

Reconciliations can be canceled.

Bank and Credit Card Statement Reconciliations 

You can reconcile bank or credit card statements with journal entries once you have recorded these statements in the system. In credit card statements, you can also designate the percentage of commission charged by the credit card company.

Reconciliations are carried out in a manner similar to that of account reconciliation. A program is activated which loads all unreconciled entries for the designated bank or credit-card company into a worksheet. Here, too, reconciliations can be performed automatically or manually.

Financial Statements 

Priority provides a broad range of reports that reflect the financial position of your company.

Financial statements may be accompanied by schedules. The structure of statements is predefined, but may be revised. For instance, you can change headings and sub-headings in a balance sheet report or add new ones.

The following list displays the standard reports provided by the system (those with asterisks are only available in the dual-currency package). All reports can be run by transaction date or by reference date, and can include pending or provisional journal entries. Additional reports can be constructed by means of a set of report generators.

Cash Flow

Priority provides two types of cash flow reports. The first documents actual cash flow into and out of the bank, sorted by cash flow code (different types of expenses and income). The second type of report is a cash flow forecast.

The Cash Flow Forecast report displays expected cash intake and outflow over a designated time period. The report is based on recorded financial transactions whose due dates fall within the specified future period. For example, expected receipts from customers are based on unpaid invoices, while forecasted payments to vendors are based on unpaid vendor invoices. You can also run the Create Provisional Entries program to record temporary journal entries for open orders, unpaid goods receiving vouchers and unbilled transactions, which can then be included in cash flow forecast reports. This program allows you to create separate entries for each transaction, include pre-payments, include or exclude taxes and exclude individual purchase orders. Orders with the Draft status are automatically excluded.

In addition, you can include anticipated cash flow that is not based on orders and invoices (e.g., salaries) by recording them in the Cash Flow Forecast Sums form.

Financial Report Generators 

In addition to the wide variety of standard financial reports available in the system, Priority provides a set of report generators that enable you to create reports with an unlimited number of structures and criteria. These generators are easily operated by the average user, and are particularly useful for accountants and comptrollers.

Ledger Report Generators

This pair of generators is used to design reports of transactions recorded against ledger accounts (GL, A/R and A/P). One generator calculates opening balances and sorts transactions by their transaction dates (which determine the fiscal period in which they fall); the other uses their reference dates (the date on which the transaction actually occurred). The latter is particularly useful when dealing, for instance, with vendor invoices that were received late.

In both cases, you select the columns to be included in the report, determining the order in which they appear. Column titles and widths are assigned automatically, but may be revised.

Transaction Report Generator

This generator can be used to design reports for account transactions based on a variety of criteria (e.g., budget items). Reports can be detailed (i.e., display information for individual transactions), or they can summarize financial data. Moreover, consolidated reports can be produced.

As with the ledger report generator, the user determines the columns to be included in the report, the order in which they will appear, their titles and widths. You can also select the columns that will serve as input parameters for the report.

Financial Statement Generator 

This generator is used to customize financial statements: balance sheet, profit and loss reports and trial balances, including schedules.

Priority breaks down each user-designed statement into two main components: a set structure of rows and a set structure of columns (column bar).

The row design determines the items which will appear (e.g., Fixed Assets, Equity, Current Liabilities), including sub-totals and/or totals; the groups of accounts attached to each item; the amount of detail that will be displayed per item (per account versus item total); and the like.

The column bars determine how the data for each row is presented. For instance, to compare quarterly figures, you would include data for each quarter in a separate column. To create a consolidated report, you would need each company’s data in a separate column, followed by a column of totals. Or you can include a percentile column (e.g., percentage of income) alongside a column of figures.

Rows and columns are defined separately, affording you the flexibility to mix and match. For example, you can use the same balance sheet items and present them with monthly figures (Column Bar A), quarterly figures (Column Bar B) and consolidated figures (Column Bar C). When running the report, the user selects not only the type of report desired (e.g., balance sheet, P&L), but also the column bar to use.


Schedules can be attached to any statement. In fact, you can attach more detailed schedules to less detailed ones in a recursive fashion. More experienced users can create complex statements, with a hierarchy of attached schedules (e.g., a factory-wide summary, a detailed report with department figures, and an even more detailed report with balances for each account).

Cost of Goods Sold 

By means of the COGS module, Priority records the cost of inventory transactions in the general ledger. This in turn allows for the financial tracking of purchases and sales from a variety of perspectives. It also provides the ability to track other types of inventory transactions in the system, such as inter- warehouse transfers, inventory disposals and the like.

Default Accounts for Transactions 

Default GL accounts can be set up for various inventory transactions and for variances.

Some of these accounts are credited or debited immediately:

Income – both taxable and tax-exempt sales are credited (in two separate accounts) when the customer invoice is recorded.

Materials Inventory/Purchases – all purchases are debited when the vendor invoice is recorded.

Price Variance – any variance between standard price and invoice price is credited or debited when the vendor invoice is recorded.

Other inventory transactions are recorded in the entry journal when the Post Cost of Goods Sold program is run:

Cost of Goods Sold – COGS for materials, labor, burden

Other Inventory – all labor and machinery (burden) costs attached to inventory

•Variance between standard and actual labor and burden costs (labor efficiency variance, burden efficiency variance)

Material Efficiency Variance – the variance between issued materials and parent-child ratios in the BOM, as well as variances created by rounding when backflushing reported production on the floor

AssemblyVariance–the variance between the standard cost of an assembled part and the standard costs of its assembled components (e.g., when the assembly quantities differ from the BOM)

•Variance generated by changes in standard part costs

•Variance created by inventory conversions

Offset – labor and burden offsets

Inventory Count Variance – the value of any variances in inventory counts

Inventory Disposal – the value of any inventory disposals

Part Sampling – the value of any inventory sampling for laboratory tests

Production Costs – the value of any issue of supplies to the plant floor.

Note that the above list of accounts only applies if you are basing COGS on standard costing. If, instead, you choose to work with actual costs, the following occurs:

•All inventory costs are posted to the same account (Materials Inventory/Purchases);

•All COGS values are posted to the same account (COGS–Materials);

•The variance accounts (except for Inventory Count Variance) are disregarded.

Greater Differentiation of Accounts 

Priority allows you not only to set up a single default account for each type of transaction, but also to create separate accounts — one for each warehouse, each accounting family or even each family within each warehouse. In addition, you can assign income and COGS accounts per customer group.

Account for each warehouse If a separate account has been assigned to a warehouse that is involved in an inventory transaction, the value of the transaction is recorded in the special warehouse account as opposed to the general default account.

Account for each accounting family Another alternative is to assign separate accounts per accounting family. Consequently, whenever a transaction involves a part in this family, the cost is recorded in this account as opposed to either the general default account or the account assigned to the warehouse.

Note that the assignment of parts to accounting families is completely separate from their assignment to part families in the Marketing and Sales and Purchasing modules.

Accounts for families within warehouses You can also maintain account balances per accounting family within a specific warehouse (with the exception of plant-floor warehouses). If an account has been assigned to a family in a warehouse, the transaction cost is recorded against this account (as opposed to all other possibilities) whenever a part belonging to this family and located in this warehouse is involved.

This is the most complex method of managing inventory, obtaining the most detailed results. For example, it allows the management of account balances according to production lines in a specific warehouse.

Accounts for customer groups Finally,you can assign default income and COGS accounts to individual customer groups, enabling you to track income and the cost of goods sold for different categories of customers (e.g., from different geographical areas) in the general ledger. This will override both types of income accounts (taxable and tax-exempt) as well as all three types of COGS accounts (materials, labor, burden) assigned on a system-wide basis. It will not override accounts designated per warehouse or family.

COGS Reports 

A variety of reports help to explain the results of the COGS program:

  • Variances from Rounding – 2nd Curr
  • Variances from Assemblies – 2nd Curr
  • Variances from Inv. Conv. – 2nd Curr
  • Actual vs Standard Issues – 2nd Curr
  • Actual vs Std Production Costs –2nd Curr
  • Price Variance Analysis
  • COGS Details per Part
  • COGS Posting Preview
  • COGS Transactions per Account
  • Details of COGS Transactions
  • Actual vs Std Production Costs
  • Actual vs Standard Issues
  • Variances from Inv. Conversions
  • Variances from Assemblies
  • Variances from Rounding
  • Standard Inv. Cost Variances
  • Std Inv Cost Variances – 2nd Curr


Most computerized systems manage budgets by opening accounts in the general ledger. This means that an expense is not recorded in the budget account until its invoice is received. Yet, in practice, there are likely to be charges against the budget (such as purchase orders or recorded receipts of materials) for which invoices have not yet been received, and therefore there will be no indication of them in the budget account.

In Priority, charges to the budget are traced through the entire chain of purchasing transactions: from the purchase requisition to the purchase order to warehouse receipts and finally the invoice. This is achieved by “rolling” charges from one stage to the next (requisition to order, order to receipt and so on) as each transaction is recorded. This tracing of budget charges may also take place for income items recorded in sales transactions.

Priority’s online budget control checks for deviations from the budget each time a transaction is recorded, resulting in an error or warning message whenever a deviation is encountered. A financial constant determines the level at which budget deviation is checked; that is, if deviation is checked on a monthly basis, a message is received as soon as the monthly budget is exceeded. If, however, deviation is checked on an annual basis, a message is only received when the entire annual budget has been exceeded.

Budget Trees and Versions 

Budgets are created in Priority using a hierarchical “tree” structure. The system allows for the creation and maintenance of an unlimited number of budget versions. Each version consists of a list of budget items that have been assigned monthly appropriations of funds. Budget versions are generally distinguished by different monetary appropriations. Only one version of the budget may be in effect at a time. All other versions are considered drafts. The use of budget versions allows you flexibility in changing and planning budgets.

Although budgets are managed separately from general ledger accounts, several types of relations may be established between the two:

• One budget item to one account;
• The same budget item to several accounts;

• The same account for several budget items.

If a given budget item is assigned its own GL account, designation of the account in a given transaction will determine the budget to be charged. Similarly, if the GL account has been assigned its own budget item, designation of the latter will determine the account to be debited or credited.

Priority provides a sophisticated mechanism for defining budget trees top down on up to five levels, with the actual budget items on the lowest level. Budget items can be predefined for the various levels of the budget tree, similar to the way predefined part parameters are used to create parts. You can define rules for each item that protect the integrity of the budget hierarchy. For example, unless a given budget category is flagged to allow additional sub-categories, you will receive an error message if you try to define a new item beneath it. The system automatically checks each new item for conformity with these rules.

As mentioned previously, the Budget Explorer allows you to open each budget hierarchy and view the details of each value on each of its levels.

You can also run the Budget Analysis (OLAP) report to view cross-sections of budget data on every level of the tree.

You can compare budget appropriations with actual expenses and income by attaching budget items to specific financial transactions, or by attaching them to an item in a relevant purchasing, sales or inventory transaction (i.e., purchase requisition, purchase order, goods receiving vouchers, vendor invoice, sales order, customer shipment or invoice). When budget items are tracked in this fashion, you can compare appropriations and expenses/income through the entire chain of financial transactions. That is, you can view not only billed transactions, but also unbilled transactions, open orders and open PRs.

Maintenance of budget versions is made easy by tools that allow you to copy versions, update and add to existing versions, and delete outdated ones. Furthermore, you can change the sums in a budget version that is in effect, and the change will be documented in a log.

Maintenance of budget versions is managed via statuses using the graphic BPM Flow Chart Budget Versions. After defining the necessary statuses (and the paths that connect them), you can view their attributes in the Statuses for Budget Versions form.

Budget Reports 

  • Budgeted vs. Actual
  • Budget Version (Graph)
  • Budgeted vs Actual as of Date
  • Budgeted vs. Actual – Detailed
  • Summary of Budgeted vs. Actual
  • Consolidated Budget vs. Actual
  • Profit and Loss for Budgets
  • Print Budget Version
  • Comparison of Budget Versions
  • Transactions w/out Budget Item
  • Print Budget Version (Tree)
  • Budget Analysis (OLAP)

Cost Allocation

The cost allocation module enables you to analyze the profitability and costs of various portions of your enterprise. This is achieved by defining profit centers and cost centers. Profit centers incur direct costs and generate revenues. Cost centers incur indirect costs that are then distributed among various profit centers.

Analysis of the profitability of profit centers and/or the accumulated expenses of cost centers is carried out on the basis of journal entries recorded for these profit and cost centers.

Profit Centers 

Division of a given enterprise into profit centers depends on your organization’s specific needs. For instance, in a manufacturing setting, a profit center might encompass an individual warehouse, a specific product line (i.e., an accounting family), a product line within a given warehouse, and so on. In a non-manufacturing setting, each project or division might be considered a separate profit center. Alternatively, a profit center might encompass a particular group of customers.

Priority allows you to define a single warehouse, accounting family or family in a warehouse as a unique profit center. Consequently, any financial transaction involving this warehouse or family will automatically be attached to the profit center in question.

Priority allows you to maintain up to five different groups of profit centers, to which you can assign all invoice and journal entry items. You can also organize profit centers into a hierarchical structure of up to three levels in a profit center tree.

All profit center reports display data for all five groups of profit centers, including pending transactions. Profit centers that are no longer in use can be flagged as inactive.

Cost Centers 

Cost centers incur indirect costs that are then applied to one or more profit centers. As with profit centers, division of a given enterprise into cost centers depends on your organization’s specific needs. For instance, you might make the entire sales department into a single cost center, or you may split it into several different cost centers (office expenses, travel expenses, etc.). You might also make a materials warehouse into a cost center, so as to calculate its periodic costs.

A given cost center is tied to various profit centers (an individual warehouse, an accounting family or a combination thereof). Each cost center is assigned a base of allocation that determines how its indirect costs will be distributed among the profit centers linked to it.

Like profit centers, you can organize cost centers into a hierarchical structure of up to three levels (i.e., a cost center tree). All cost center reports display data for all five groups of cost centers, including pending transactions. Cost centers that are no longer in use can be flagged as inactive.

Bases of Cost Allocation 

A base of allocation determines how a cost center’s indirect costs are distributed among profit centers. This entails the designation of three main factors:

• Which profit centers are to absorb the indirect costs

• How to divide the costs among the profit centers

• At what date the current allocation ratio will expire.
Cost center costs are distributed among profit centers for a designated period in one of two ways:
• By weighted parameter

• By direct cost.

Cost Allocation by Weighted Parameters 

Priority allows you to allocate indirect costs among various profit centers according to weighted parameters — such as area, number of employees, sales volume. Thus, for instance, a profit center with a greater number of employees will absorb more costs that one with a smaller work staff.

Cost Allocation by Direct Costs 

Another way to distribute indirect costs is in terms of the direct costs incurred by the profit centers. This method is especially useful when the distribution of expenses is related to the profit center’s changing volume of activity. Thus, a profit center with greater activity (and more direct expenses) over a given period will absorb more indirect costs.

Cost Allocation Reports 

Profit Center Reports 

  • List of Profit Centers
  • Profit Center Analysis
  • Profit Center Tree Analysis
  • Profit Center Costs
  • Profit Ctr Costs by Expense Acct
  • P&L Statement per Profit Center
  • Consolidated P&L per Profit Ctr
  • Profit & Loss Summary
  • Profit Center Analysis (OLAP)
  • Profit/Cost Ctr Analysis (OLAP)

Cost Center Reports 

  • List of Cost Centers
  • Bases of Cost Allocation
  • Cost Summary
  • Cost Summary by Tree
  • Cost Center Analysis

Financial Interfaces 

The financial interfaces offered by Priority are useful for importing/exporting accounting data both from or to an external system and between companies (in a multi-company enterprise).

Account Interface 

The Account Interface is used to transfer account numbers and names from one company to another. Account data are downloaded from each source company or program into an ASCII file and are then loaded into the target company in two stages: first, they are loaded into an interim table where they can be checked and any necessary revisions made; next, they are loaded from the interim table into the ledgers. When transferring data, you can add a prefix that will distinguish one company’s accounts from another’s.

Journal Entry Interface 

The Journal Entry Interface can be used to transfer entries from an external system (e.g., payroll). The interface can also be used to load entries for transfer accounts from one company branch to another. This is necessary when distributing expenses among branches, where the data for each branch is stored in a separate installation. Finally, it can be used to export data to other financial or accounting applications.

As with the account interface, journal entry data are downloaded from each source company into an ASCII file and loaded into the target in two stages: first, they are loaded into an interim table where they can be checked and revised; next, they are loaded from the interim table into the entry journal.

Interface for Importing Data 

Priority has the ability to import data files from external programs through a variety of interfaces. The imported files must be ASCII files, configured in the appropriate manner for each interface. The importing of external data is especially useful during the initial stages of setting up the system and results in a speedier transition from the previous work environment to Priority.

The following types of data can be imported from external programs:

  • Chart of Accounts
  • Chart of Accounts Receivable
  • Journal Entries
  • Chart of Accounts Payable