Banking Ledger ER Diagram
The code
erDiagram
CUSTOMER ||--o{ ACCOUNT : holds
ACCOUNT ||--|{ TRANSACTION : records
TRANSACTION ||--|{ LEDGER_ENTRY : splits_into
ACCOUNT {
string iban
string currency
decimal balance
}
TRANSACTION {
string reference
timestamp booked_at
}
LEDGER_ENTRY {
decimal amount
string direction
}
CUSTOMER {
string name
string tax_id
}
How this template works
Financial systems demand the most disciplined schemas, and this diagram shows the minimum viable shape of one. Customers hold accounts, accounts record transactions, and each transaction splits into ledger entries that carry the actual amounts. The structure mirrors double-entry bookkeeping, where every movement of money is captured as balanced entries rather than as a single mutated balance.
The three relationship lines each tell a story. CUSTOMER ||--o{ ACCOUNT : holds allows a customer to open several accounts, including joint arrangements where a second customer row shares the account. ACCOUNT ||--|{ TRANSACTION : records insists that an account has at least one transaction, which is true the moment it is opened with a deposit. TRANSACTION ||--|{ LEDGER_ENTRY : splits_into is the heart of the model, because a transfer between two accounts produces at least two entries, one debit and one credit. Attribute blocks use types that matter in finance, with decimal balance instead of a float and timestamp booked_at instead of a plain date, since precision and ordering are part of the correctness story.
The gotcha is naming. Attribute names with spaces will break the parser, so this template uses snake_case like tax_id and booked_at throughout. Pick one convention and hold it across every block, because a diagram that mixes createdAt and created_at looks like two different schemas stitched together. Underscores are safe everywhere, including relationship labels such as splits_into.
Adapt it by adding a CARD entity for payment instruments, a CATEGORY entity for spending analysis, or a currency attribute on LEDGER_ENTRY for multi-currency posting. Auditors tend to like this format, because the relationship lines read like invariants: exactly one account per entry, at least one entry per transaction.
Related templates that continue the theme: the e-commerce ER diagram for consumer transaction data, the employee management ER diagram for payroll-adjacent modeling, and the school system ER diagram for fee and enrollment structures. The ER diagram guide documents the notation end to end.
Variations to try
- Add a CARD entity linked to ACCOUNT to model payment instruments separately from the account itself.
- Extend LEDGER_ENTRY with a currency attribute if multi-currency posting is on your roadmap.
- Add a CATEGORY entity and link it to TRANSACTION for spending analysis.
