Implement financial management
Structure before transactions
Every question in this domain starts with setup order: legal entity → shared chart of accounts → account structures → advanced rules → financial dimensions → ledger and fiscal calendars → currencies and exchange rate types. Account structures define which main account + dimension combinations are valid; advanced rules add conditional logic (require, default, or block a dimension when another dimension or main account has a given value). A favourite trap is the global dimension flag: it cannot be changed once transactions exist, and a suspended dimension stops accepting new entries but keeps history.
Posting and closing
Know the journal families (daily, general, allocation, elimination, reclassification, reversing) and the role of posting layers and posting definitions. Posting definitions only fire when the matching transaction type is enabled for them. Reversing entries use the reversal date, not the original posting date. A fiscal period cannot be set to On hold or permanently closed while unposted journals exist for it - closing the period is a separate step from posting.
Multiple currencies
Three currencies matter: accounting (ledger), reporting (optional), and transaction. Realized gain/loss posts when a transaction is settled; unrealized gain/loss comes from the period-end foreign currency revaluation. Exchange rate types are tied to a rate provider.
Worked example
An invoice of USD 1,000 is booked when EUR/USD = 1.10, so 909.09 EUR. Payment two months later at 1.15 gives 869.57 EUR; the 39.52 difference posts to the realized gain account defined in ledger setup. Had the invoice still been open at period end, the revaluation would have hit unrealized gain/loss instead.
Rule of thumb: if the requirement says 'only certain combinations are legal', use an account structure; if it says 'if X then Y', use an advanced rule.