Recommended practices for posting profiles

There are several recommended practices that you should follow when you configure posting profiles throughout the system. This article describes different scenarios and the corresponding recommended practices.

Setting the Do not allow manual entry flag

On the Main accounts page, the Do not allow manual entry checkbox should be selected for any main account that is used for a posting profile. This setting prevents users from manually posting a journal entry to the main account. Therefore, it helps ensure that the subledger remains in balance with the general ledger and helps make the reconciliation process easier.

If adjustments are required to an account that is controlled by the system and automatically posted, you can use one of these approaches:

• Create a secondary main account where the adjustments can be posted. Then use a Total account or a special row on your financial reports to group and sum the accounts together.
• Reverse the original transactions in the appropriate subledger, make any required corrections, and then repost the transaction through the same subledger.

Changing posting profiles after transactions exist

If you change a posting profile after transactions exist, the reconciliation can fail, and your subledger and ledger can become out of balance. In general, we recommend that you not change the posting profile after transactions exist.

If changes are required, use the following guidelines to help ensure the integrity of the system:

• Make the changes during a period close.
• Make the changes when no other transactions are occurring in the system.
• Validate the ledger and reconcile it to subledger before and after you make the changes.
• Posted transactions aren't updated if you change the posting profile. Carefully consider whether any adjusting entries are required for your change.
• If you're changing inventory posting profiles, consider how the changes will affect your on-hand inventory and ledger balances. Some changes might require that you bring the inventory to 0 (zero), close the inventory, and then bring the inventory back in after the changes are made.
• Always test your changes in a non-production environment before you make them in production.

Using database logging to audit changes to posting profiles

Consider setting up database logging for each posting profile and parameters tables that control posting. Then, if a parameter or profile is changed, you will have a full audit record of what value was changed, who changed it, when it was changed, and what the previous value was. This information can be critical during your reconciliation process, and your auditor might require the supporting documentation.

For more information, see Configure database logging.

Use the following table as a reference for common table names that are related to posting profiles and related posting parameters.

Page name	Navigation path	Table name
Accounts payable parameters	Accounts payable > Setup > Accounts payable parameters	VendParm
Vendor posting profile	Accounts payable > Setup > Vendor posting profile	VendPosting
Charges code	Accounts payable > Charges setup > Charges code or Accounts receivable > Charges setup > Charges code	MarkupTable
Methods of payment	Accounts payable > Payment setup > Methods of payment	VendPaymMode
Cash discounts	Accounts payable > Payment setup > Cash discounts or Accounts receivable > Payment setup > Cash discounts	CashDisc
Payment fee (Vendor)	Accounts payable > Payment setup > Payment Fee	VendPaymFee
Accounts receivable parameters	Accounts receivable > Setup > Accounts receivable parameters	CustParm
Customer posting profiles	Accounts receivable > Setup > Customer posting profile	CustPosting
Methods of payment	Accounts receivable > Payments setup > Methods of payment	CustPaymMode
Payment fee (Customer)	Accounts receivable > Payments setup > Methods of payments	CustPaymFee
Asset leasing parameters	Asset leasing > Setup > Asset leasing parameters	AssetLeasePostingAccounts AssetLeaseJournalParameters AssetLeaseExecutoryCostPostingAccounts
Bank accounts	Cash and bank management > Bank accounts > Bank accounts	BankAccountsTable
Bank transaction types	Cash and bank management > Setup > Bank transaction types	BankTransType
Elimination rules	Consolidations > Setup > Elimination rule	LedgerEliminationRule LedgerEliminationRuleLines
Expense categories	Expense management > Setup > General > Expense categories	ProjCategories
Fixed asset parameters	Fixed assets > Setup > Fixed asset parameters	AssetParameters
Fixed asset posting profiles	Fixed assets > Setup > Fixed asset posting profiles	AssetLedgerAccounts AssetDisposalParameters
Currency revaluation accounts	General ledger > Currencies > Currency revaluation accounts	CurrencyLedgerGainLossAccount
Accounts for automatic transactions	General ledger > Posting setup > Accounts for automatic transactions	LedgerSystemAccounts
Intercompany accounting	General ledger > Posting setup > Intercompany accounts	LedgerIntercompany
Transaction posting definitions	General ledger > Posting setup > Transaction posting definitions	JournalizingDefinitionTrans
Posting definitions	General ledger > Posting setup > Posting definitions	JournalizingDefintion
Posting (Inventory)	Inventory management > Setup > Posting > Posting	InventPosting
Cost type codes	Landed cost > Costing setup > Cost type codes	ITMCostTypeTable
Resources	Production control > Setup > Resources > Resources	WrkCtrTable
Resource groups	Production control > Setup > Resources > Resource groups	WrkCtrResourceGroup
Production groups	Production control > Setup > Production > Production group	ProdGroup
Cost categories	Production control > Setup > Routes > Cost categories	ProjCategory
Project groups	Project management and accounting > Setup > Posting > Project groups	ProjGroup
Ledger posting setup (Projects)	Project management and accounting > Setup > Posting > Ledger posting setup	ProjPosting
Default offset accounts for expenses	Project management and accounting > Setup > Posting > Default offset accounts for expenses	ProjDefaultOffsetSetup
Rebate management posting profiles	Rebate management > Rebate management posting setup > Rebate management posting profiles	TAMRebatePosting
Ledger posting group (Tax)	Tax > Setup > Sales tax > Ledger posting group	TaxAccountGroup

Changing groups after transactions exist

Use caution when you change groups in master data. If you're using groups to define your posting profiles, any change to a group on a master record can have a negative impact on the ability to reconcile the ledger to the subledger. For example, you can configure the inventory posting profile for sales order revenue so that a different revenue account is used for each item group. If you change the item group that is assigned to an item after transactions exist, the revenue on new transactions will be posted to the updated account. However, any revenue that was posted before the change will remain in the original account.

Testing posting profiles

Before your go-live, and after you make any changes or additions to your posting profiles or related parameters, you should test each scenario. At a minimum, you should test each posting type to validate that posting works correctly. However, the recommended approach is to test each posting profile transaction and combination.

For example, you have two customer posting profiles, each of which has three records that are specific to customer groups. In this case, you should test each transaction type.

Posting profiles:

• GEN – The general posting profile that has one group for employees, one for customers, and one for intercompany. Each group points to a different Accounts receivable Trade account.
• PRE – The prepayment posting profile that has one record for all prepayments that points to the Customer prepaids accounts.

Testing scenarios

• Free text invoice for a customer in the Employee group that uses the GEN posting profile
• Free text invoice for a customer in the Employee group that uses the PRE posting profile
• Sales order invoice for a customer in the Employee group that uses the GEN posting profile
• Sales order invoice for a customer in the Employee group that uses the PRE posting profile
• Customer payment journal for a customer in the Employee group that uses the GEN posting profile
• Customer payment journal for a customer in the Employee group that uses the PRE posting profile

For the preceding example, repeat one testing scenario for each customer group, and repeat each group of testing scenarios for each additional transaction type (for example, project invoices and service management).

Reconciling the ledger to the subledger

The ledger should be reconciled to the subledger every period. Many modules contain out-of-box reports that can be used to help do this reconciliation. However, depending on your local requirements, you might have to develop custom reports or extend the existing reports to meet your reporting requirements.

We recommend that you do a mock period close and reconcile each of your subledgers to the ledger before your go-live. We also recommend that you do a mock cutover of all open balances and open transactions before your initial go-live. As part of this process, you should run a complete reconciliation to ensure that the migration of balances and open transactions balance with the legacy systems, and that all subledgers balance with the ledger before new transactions are created.