One Ledger Per Member/Vendor: Refactoring Django Ledger Architecture

[codefilterPH]

I recently refactored part of my Django Ledger implementation related to customer/member/vendor transaction handling and ledger lifecycle management.

Previously, the system created a new LedgerModel for nearly every transaction type (savings deposits, withdrawals, share capital payments, loan payments, vendor transactions, etc.). While technically functional, it eventually produced multiple fragmented ledgers per member/vendor, which became difficult to manage operationally and felt inconsistent with traditional accounting subledger practices.

Previous Structure

Member/Vendor Juan
 ├── Ledger #1 → Savings Deposit
 ├── Ledger #2 → Share Capital
 ├── Ledger #3 → Withdrawal
 ├── Ledger #4 → Loan Payment
 └── Ledger #5 → Share Capital

After refactoring, each member/vendor now maintains a single reusable canonical ledger that acts as the long-term transactional container:

Member/Vendor Juan
 └── Canonical Ledger
      ├── JE #1 Savings Deposit
      ├── JE #2 Share Capital
      ├── JE #3 Withdrawal
      ├── JE #4 Loan Payment
      └── JE #5 Share Capital

Refactor Details

The implementation changes included:

• Refactoring create_ledger() to reuse an existing ledger via get_or_create()
• Introducing a deterministic ledger_xid convention such as:

member-<customer.uuid>
vendor-<vendor.uuid>

• Creating a migration/maintenance management command capable of:

  • identifying duplicate member/vendor ledgers
  • consolidating Journal Entries into the canonical ledger
  • safely removing redundant ledgers after migration

Why This Feels More Appropriate

This structure aligns more naturally with real-world accounting and counterparty-based financial systems, particularly for:

• cooperatives
• banking-style member accounts
• customer/vendor subledger management
• lending systems
• long-term account history tracking
• consolidated reporting and audit navigation
• cleaner Journal Entry organization

Operationally, it also simplifies:

• ledger discovery
• member/vendor account review
• statement generation
• reporting aggregation
• audit tracing
• UI navigation

I also came across earlier discussions suggesting that ledgers are often more effective when treated as persistent reusable subledgers per customer/vendor/member, rather than ephemeral containers generated per transaction workflow. That perspective strongly influenced this redesign.

So far, the refactor has made the accounting structure significantly cleaner and easier to reason about, especially in cooperative, lending, and member-centric financial workflows.

Would appreciate hearing how others using Django Ledger are handling customer/member/vendor ledger architecture in coop, lending, banking, ERP, or subscription-style systems.

[codefilterPH]