You will usually use the account code or number that is used in the accounting source system as the element name for account elements in the operational chart of accounts (FIN OCoA). This might become an issue if the same code is used in different source systems or different entities for a different purpose and can’t be mapped to the same position in the balance sheet rollup.
An easy solution to this problem is to use a prefix for the account code. This could be the entity code or an abbreviation of the accounting standard or similar. Usually, a “.” is used as the delimiter, but any delimiter or no delimiter could be used as well.
If the build of the required reporting rollup requires to map accounts differently based on for example the cost center, a suffix could be used.
While the account code on the lowest level is usually determined by the source system, the reporting structure for balance sheet and P&L is often “handcrafted”. It is recommended to use a logical code or numbering system rather than just names or descriptions. This makes sorting and finding elements easier.
As you learned in the basic training, new accounts can be added by the data load process and should at the very least be added to the “Total GL Accounts” node - this will allow you to check the integrity of the data, i.e. that Total GL Accounts is equal to zero for any given company and period.
Important: Before any further processing makes sense, the newly created accounts need to be mapped to a Balance Sheet or P&L position (somewhere under the node that you defined as C3_MGMTTB). The system needs this mapping to correctly determine the Trial Balance Multiplicator (TB_Mult), which is used to flip the sign for non-asset accounts when by using it as a multiplier for the TB measure to calculate OPV.
If possible, the mapping should take place immediately. If assigning the new accounts to their parent node cannot happen from a source system, it will need to be done manually by the user. If this cannot happen in a timely manner, a viable option is to create two “park” positions like “Unmapped Assets” and “Unmapped Equity and Liabilities” in the main balance sheet structure. Often it is possible to make this distinction by the first digit of the account code (e.g. asset accounts always start with “1…”). If this is achieved the full processing can happen right away and a user can deal with moving the accounts from the parking spot to the correct position, which will not cause the TB_Mult to change as long as an asset is still an asset.
If the source systems account codes are well structured FPM’s automatic account mapping feature might be a good fit. All it requires is filling the “NoFrom” and “NoTo” attributes on the positions that the new accounts should be mapped to. The automatic mapping will then work if the new account is within the range and there is only one applicable range found.
You can also use different mapping ranges (e.g. for different sources or entities). To achieve this, create a node under the “Automatic Mapping” position and add the new accounts as children to this position. You further need two additional attributes. See an example in the following walkthrough.
If you would like to try this yourself, here are two Excel files that can be loaded to the chart of accounts automation:
Natural Accounts under Automatic Mapping: 
Range attributes: 
Besides the main rollup there will usually be additional reporting rollups required. Typical examples are management vs. legal P&L structure or rollups for the representation of a local GAAP. This can be done quite easily by loading from an Excel template or manually building the structure in the CoA Maintenance. Caution is in order when creating this structure. To avoid confusion, it is advisable to use a common prefix for the reporting positions within on rollup. E.g. if you have an element “EBITDA” in your main rollup and there is a management P&L as well, use a prefix like “M_EBITDA”.
To keep the ongoing maintenance at a minimum, try to map common elements on the highest possible level.
The initial load of reporting rollups can conveniently be done by loading from Excel and is recommended at the beginning. After this, incremental changes to the structure could well be done directly in the frontend. If that is the chosen solution, the automation step of the initial load should be deleted or at the very least be deactivated. Accidentally executing the automation step will otherwise compromise the rollup that has been manually modified.
If attributes need to be localized you have seen already, how to achieve this through the dimension definition. It is recommended to maintain the unlocalized attribute value in the most commonly used language in the organisation.
Example: If the main language in your organisation is English and some users prefer to see a German “Description” attribute, create only two attributes “Description” and “Description [de]”. You don’t have to create a third attribute “Description [en]”, the unlocalized “Description” will be displayed automatically, also filling any blanks in additional locales.
For the chart of accounts the attribute “Code and Description” will be calculated automatically if you simply create the localized version, e.g. “Code and Description [de]”.
For reporting purposes Apliqo UX supports using attributes to apply a row format in tables. Any standard classes as well as custom CSS classes can be maintained in attributes. Any attribute name could be used but we recommend using rowFormat, rowFormat2 etc. When you create additional attribute, you should assign them to the group “Row Format” to allow previewing in the CoA maintenance.
