Skip to main content

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 https://api.korastratum.com/api/v1/cba/gl/operations-mapping \
-H "Authorization: Bearer $TOKEN" \
-H "X-Tenant-ID: demo_bank"

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.

warning

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.

note

IFRS stage migrations trigger automatic recalculation of expected credit loss (ECL) provisions. The GL service posts the provision adjustment journal immediately.

Next Steps