Operations Mapping
GL operations mappings define which GL offset accounts are used when the system automatically posts journal entries for different transaction types. Instead of hardcoding account references, each transaction type is mapped to the correct debit and credit GL accounts through configuration.
How It Works
When a transaction occurs (e.g., an interbank transfer fee), the GL service looks up the operations mapping for that transaction type to determine:
- Which GL account to debit
- Which GL account to credit
- The journal type and description template
This decouples business logic from accounting configuration, allowing operations teams to adjust GL posting rules without code changes.
List Operations Mappings
GET /api/v1/gl/operations-mapping
- cURL
- Node.js
- Python
- Go
curl https://api.korastratum.com/api/v1/cba/gl/operations-mapping \
-H "Authorization: Bearer $TOKEN" \
-H "X-Tenant-ID: demo_bank"
const mappings = await cbaRequest("GET", "/api/v1/gl/operations-mapping", token);
mappings = cba_request("GET", "/api/v1/gl/operations-mapping", token)
mappings, err := cbaRequest(ctx, "GET", "/api/v1/gl/operations-mapping", token, nil)
Response:
{
"mappings": [
{
"id": "mapping-uuid",
"operation_type": "INTERBANK_TRANSFER_FEE",
"description": "NIP transfer fee collection",
"debit_account_id": "receivable-uuid",
"debit_account_code": "1300-001",
"credit_account_id": "fee-income-uuid",
"credit_account_code": "4100-001",
"journal_type": "FEE",
"is_active": true,
"created_at": "2026-01-15T10:00:00Z"
}
]
}
Create a Mapping
POST /api/v1/gl/operations-mapping
{
"operation_type": "LOAN_DISBURSEMENT",
"description": "Loan disbursement to customer account",
"debit_account_id": "loan-asset-uuid",
"credit_account_id": "customer-deposit-uuid",
"journal_type": "LOAN"
}
Requires officer role.
Update a Mapping
PUT /api/v1/gl/operations-mapping/:id
{
"description": "Updated description",
"debit_account_id": "new-debit-uuid",
"credit_account_id": "new-credit-uuid"
}
Requires manager role.
Changing a mapping affects all future automatic GL postings for that operation type. Existing posted journals are not retroactively modified.
Delete a Mapping
DELETE /api/v1/gl/operations-mapping/:id
Requires manager role. Deleting a mapping will cause automatic GL posting to fail for that operation type until a new mapping is created.
IFRS Classifications
The platform supports IFRS 9 financial instrument classification for regulatory reporting.
Get IFRS Summary
GET /api/v1/gl/ifrs/summary
Returns an aggregated view of financial instruments by IFRS classification stage.
Response:
{
"summary": {
"stage_1": {
"label": "Performing",
"total_exposure": 5200000000.00,
"expected_credit_loss": 52000000.00,
"instrument_count": 12450
},
"stage_2": {
"label": "Underperforming",
"total_exposure": 800000000.00,
"expected_credit_loss": 48000000.00,
"instrument_count": 890
},
"stage_3": {
"label": "Non-Performing",
"total_exposure": 150000000.00,
"expected_credit_loss": 112500000.00,
"instrument_count": 120
}
},
"as_of_date": "2026-04-07"
}
List IFRS Classifications
GET /api/v1/gl/ifrs/classifications
Returns individual instrument classifications with their current IFRS stage.
Migrate an Instrument Stage
Move a financial instrument between IFRS stages (e.g., from Stage 1 to Stage 2 when credit risk increases significantly).
PUT /api/v1/gl/ifrs/classifications/:id/migrate
{
"target_stage": 2,
"reason": "Significant increase in credit risk - 60 days past due",
"effective_date": "2026-04-07",
"migrated_by": "user-uuid"
}
Requires manager role. Stage migrations are audited and create corresponding GL provision adjustments.
IFRS stage migrations trigger automatic recalculation of expected credit loss (ECL) provisions. The GL service posts the provision adjustment journal immediately.
Next Steps
- General Ledger — Chart of accounts and journal posting.
- Financial Reports — IFRS-compliant financial statements.
- Fiscal Periods — Period management for reporting.