Developer reference
Financial semantics
Keep actual money, future commitments and real-world context distinct in every service and UI.
The domain explains financial meaning beyond table structure. A plan, a payment and a person can be connected without being the same fact.
Read the core contracts
- Money and currencies: movement types, currency and user-day dates.
- Ledger and account evidence: balance basis and corrections.
- Exchange evidence: reference quotes versus actual exchanges.
- Subscription lifecycle: recurring expectations versus charges.
- Import lifecycle: reviewed source and explicit financial consent.
- Service boundaries: where validated effects happen.
Ask what actually happened
A transfer is not new income. A repayment is not another purchase. An existing loan agreement is not new cash. An income source is not a received salary.
For a fictional EGP 350 bill due 10 October 2026, the obligation is future context. The actual payment needs its own account and settled date.
Preserve uncertainty
A dated user-stated balance is a valid starting basis without claiming bank verification. Missing history and unsupported conversion remain visible. A failed read is unavailable rather than zero.
Use these distinctions when changing request validation, services, summaries and customer language. A balanced transaction can still be misclassified, so verify both its math and intent.