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​