Anyone who has spent time in the finance department of a bank or fund has seen this happen. At the end of the day, the figure in the deposit system does not match the figure in accounting, and someone has to go through the transactions one by one to find where the difference came from. Sometimes a manual voucher was forgotten, sometimes a transaction was recorded in one system but not in the other, and sometimes a brief network outage struck right in the middle of a transfer.
These discrepancies are usually not the result of careless staff; their roots lie in the architecture. When the deposit system keeps the account balance in its own table, the card system keeps the credit balance in its own table, and accounting keeps the balances of those same accounts under its own account headings, there are three figures for a single fact. However carefully they are synchronized, sooner or later one of those figures drifts away from the others.
The decision we made at Dara
In Dara, no module has a balance column. Deposits, wallets, credit cards, financing and the investment portfolio read balances from the Financial Core and post anything with a financial effect to that same core as a voucher. The deposit module holds information such as the account number, account holders, category and policies, but the balance itself is known only to the Financial Core.
For this to work, the chart of accounts has to accommodate that level of detail. Dara's chart of accounts goes down to six detail levels, and detail accounts are floating. Every deposit account, every wallet and every financing contract has its own dedicated detail account under the relevant account heading. As a result, a customer's detail account turnover is the very statement they see in the app, and no other source is needed to produce it.
How withdrawals are controlled in this model
Before recording a withdrawal, the deposit module fetches the available balance from the core: the account's sub-ledger balance minus any active holds. If the amount is sufficient, the withdrawal voucher is posted to the core, and only then is the operation's status updated in the module itself.
The order of these two steps matters. If the connection drops midway, either the voucher was not posted and nothing has happened, or it was posted and the module finds it on the next attempt. There is no scenario in which money has moved without a voucher behind it.
Duplicates are another issue. Networks sometimes lose a response, and the sender then resubmits the same request. In Dara, every voucher posting request carries an idempotency key. If a request arrives with a key that has already been used, the core returns the original voucher instead of creating a second one.
Three-stage vouchers and sequence numbers
A voucher in the Financial Core goes through three stages: draft, provisional and final. Transitions between these stages are controlled by the system itself, and a final voucher can no longer be edited. A credit card purchase is a good example. At the moment of purchase, a provisional voucher is posted and the customer's available credit goes down; once the merchant confirms the purchase, that same voucher becomes final.
Voucher sequence numbers in each fiscal period are drawn from a counter dedicated to that period, and the counter never moves backward. An auditor sees a continuous run of numbers, with no gaps and no duplicates.
What changes for the finance department
- Reconciliation between subsystems disappears from the end-of-day routine, because there is no second figure to reconcile. Reconciliation against bank statements still has its place and is handled in Treasury.
- Financial reports, from the trial balance and general, subsidiary and detail account turnover to the balance sheet, are built from the same data the teller works with.
- The figure a customer sees in the app is the same as the figure in the period-end report.
- Adding a new product, such as a new type of wallet or card, does not mean rewriting balance logic. The new module simply connects to the same core.
The cost of this decision
This architecture has its costs too. Every module depends on the Financial Core to read balances, so the core must always be available and responsive. That is why balance reads in the core are kept simple and all voucher posting goes through a single path. In the deployment design for each project, the Financial Core is also the most critical component, and its capacity is planned separately.
Even so, in our view, keeping one stable core running is simpler than reconciling several competing figures every day, for the technical team and the finance department alike. Most of Dara's other design decisions, from the Process Engine to the wallet, rest on this same foundation.
- #Financial_Core
- #Architecture
- #Reconciliation
- #Accounting_voucher
