Background

Anyone moving into consolidation and reporting from a technical background eventually finds that designing the system takes as much of an accounting mindset as an engineering one. That was the case for me on HFM and FCCS, where debits and credits were (and still are) tricky terms for most engineers, and they took me longer to work out than most other things in the product. What made them difficult was not just the accounting definition but also the way the system handles the signage of the data.

Two different sign conventions

A trial balance extracted from a general ledger(GL) normally follows a debit positive convention, where every debit is a positive number and every credit is a negative number irrespective of the account it belongs to. On that basis a revenue/liability/equity account arrives as a negative number, and the assets/expense account arrives as a positive number.

Contrary to GL, the data in FCCS is normally held in reporting signage instead, which means the normal balance of every account is stored as a positive number and a report reads correctly without any sign reversal being applied to it. Most of the sign problems on an implementation start at the point where those sign two conventions meet.

How account type defines the signage

The account type assigned to a account tells the system what a normal balance looks like for that account, and a positive number in the cube always represents more of whatever that account normally holds:

Account type	Normal balance	Debit stored as	Credit stored as
Asset	Debit	Positive	Negative
Expense	Debit	Positive	Negative
Revenue	Credit	Negative	Positive
Liability	Credit	Negative	Positive
Equity	Credit	Negative	Positive

What this means for the data coming in

A trial balance loaded in debit positive signage without any treatment produces balances that read correctly for the assets and expenses while every other account is inverted, and the best place to handle this is in Data Exchange rather than in the metadata.

The change sign feature in Data Load Mappings converts the incoming values into reporting signage for the affected accounts before they are written to the cube, which keeps the correction inside the integration and leaves the dimension untouched.

How debits and credits in journals impact the balances

Consolidation Journals in FCCS require a minimum of two lines, one for the debit and one for the credit, and both amounts are entered as positive values in their respective columns with the total debits equalling the total credits.

In the below journal example, a cash account (with an Asset account type) has a debit entry and a Sales account (with a Revenue account type) has a credit entry, both entered as positive amounts.

1. The cash account returns the debit as a positive number — a debit is the normal balance for an account with an Asset account type.
2. The Sales account returns the credit as a positive number — a credit is the normal balance for an account with a Revenue account type.

Neither account returns a negative value, and both amounts are now held in reporting signage rather than in the convention they were entered in.

Before the journal

Journal (debit entry for Asset, credit entry for Revenue)

After the journal

If you reverse the entries for the same two accounts, so that the cash account is credited and the Sales account is debited, the data retrieval returns both amounts as negative numbers with the same magnitudes as before.

Journal (credit entry for Asset, debit entry for Revenue)

After the journal with debit/credit reversed

This is also why a journal that balances is not the same thing as a journal that is correct. The debit and credit columns only have to agree with each other for the journal to post, and whether the resulting balance moves in the intended direction depends entirely on the account type of each line.

Conclusion

Account type is what defines reporting signage for a member – It decides whether a positive number means a debit balance or a credit balance, so it has to be set against the convention the source system actually sends rather than against how the account reads on a report

Sign conversion belongs in Data Exchange – The change sign feature in Data Load Mappings converts incoming values into reporting signage before they are written to the cube, so the correction sits in the integration rather than in the dimension

Debits and credits describe direction rather than sign – Whether a journal line lands in the cube as a positive or a negative number depends on the account type of that line, which is why a journal that balances can still move a balance in the wrong direction

Once you know how the account type determines reporting signage, debits and credits stop being a set of rules to memorise and become something you can work out from the behaviour.