This is a challenging requirement to manage in D365 F&SCM, as there is no standard framework in the system specifically designed to manage Fixed/Term Deposits as financial instruments. The approach currently suggested (using the Fixed Assets module) could technically possible as a workaround, but I would not recommend it from an accounting, audit, and conceptual standpoint.
Fixed Deposits are financial instruments / cash investments. They are:
- Not depreciated
- Not used in operations
- Not capital assets
- They generate interest income, not depreciation expense
Managing them through Fixed Assets would likely create confusion for accountants and raise audit concerns (e.g., “Why is a bank deposit recorded as a fixed asset?”). It could also create messy IFRS/GAAP classification issues and reduce clarity in cash and treasury visibility. While it may technically work, conceptually and from an audit perspective it is not aligned with the nature of the transaction.
You also mentioned concerns about creating bulk records in the Bank module. Could you please clarify how many deposits are expected per year? If the volume is high, the same “bulk” issue would also apply to the Fixed Assets module.
There are additional risks if we use Fixed Assets:
- If a user runs a depreciation proposal without proper filtering, deposit balances could be impacted. While we can train users and configure FA groups, in practice this introduces operational risk and dependency on manual control.
- Disposal processing in Fixed Assets generates multiple ledger entries and requires setup of depreciation and disposal accounts, which is not conceptually aligned with a deposit maturity process.
- Auditors may raise significant questions about classification and accounting treatment.
Regarding interest accounting, the entry should be:
Dr. Interest Receivable
Cr. Interest Income
Using Fixed Assets may lead to incorrect posting logic (e.g., Dr FA / Cr Bank), which is not aligned with proper accrual accounting. Even if accrual functionality is used, it would likely impact only the ledger and not provide a proper subledger structure for reinvestment or compounding logic.
If we want to avoid customization entirely, the cleanest standard approach would be to manage deposits within the Bank module and process interest accruals and maturity manually through journals. While somewhat manual, this approach remains conceptually correct and audit-safe.
However, my preferred solution would be to build a lightweight Fixed Deposit submodule (custom):
- Fixed Deposit Master table (Deposit No., Bank, Principal, Start Date, Maturity Date, Rate, Status, etc.)
- Posting setup for principal, accrued interest, and income accounts
- Automated monthly interest accrual logic
- Maturity and rollover processing
- Embedded financial controls
This approach keeps:
- Accounting conceptually correct
- Bank and Fixed Asset modules clean
- Auditors comfortable
- Treasury visibility intact
I would strongly recommend we align the solution with the financial nature of the instrument rather than adapting an asset framework that was not designed for this purpose.
If you find this answer helpful, please consider verifying the answer. 👍
Regards,
Syed Haris Shah
