Mapping an app event to a GL account
Almost every figure in the ledger gets there because an app event posted it automatically. Mapping is the configuration that says which accounts an event debits and credits — so a disbursement, a repayment or an insurance premium each become a balanced journal without anyone typing it.
The path from event to journal
A loan event flows through GL account mapping into a double-entry journal, which lands in the trial balance and ultimately the period close. The mapping is the middle step: it turns a business event — money disbursed, money repaid, a premium collected — into the specific debit and credit lines the ledger needs.
Common event mappings
| App event | Debit | Credit |
|---|---|---|
| Loan disbursement | Loans receivable | Cash |
| Loan repayment (principal) | Cash | Loans receivable |
| Interest earned | Loans receivable / interest receivable | Interest income |
| Insurance premium collected | Cash | Insurance premium liability |
| Provision raised | Provision expense | Loan-loss provision |
Your own chart of accounts supplies the real account names. Note that a collected insurance premium credits a liability, never income — that is a deliberate mapping the platform enforces.
Why mapping once is safer than posting daily
- Consistency — every event of the same kind posts the same way, so the same transaction can never be booked two different ways by two people.
- Balance by construction — each mapping defines an equal debit and credit, so postings cannot unbalance the trial balance.
- Auditability — the journal records that it came from an app event, so a figure in the ledger traces back to the loan action that caused it.
For a one-off that no event mapping covers, a manual journal entry is the right tool — and it is audit-logged. See “Recording a manual journal entry.”