Case study

Double-entry accounting engine and Islamic-finance knowledge base

A ledger and rule-based accounting engine whose invariants are enforced by the database, plus a bilingual RAG over Islamic-finance standards that cites page and clause.

Client: Own R&D
Role: Architect & engineer
Timeline: Layers 1–2 of a 10-layer plan
Stack: PythonFastAPIPostgreSQLSQLAlchemyAlembicOpenAIReactTypeScript

Problem

Financial software is only as trustworthy as its ledger. Before building anything specific to Islamic finance, I wanted a foundation where the books cannot become unbalanced — through a bug, a retry or a concurrent request.

Approach & architecture

Each layer designed on paper first: domain model, full DDL, migrations, API, decisions and a commit-by-commit plan — 25 ADRs across two layers.
Ledger: double-entry journal, reversals, idempotent posting and a trial balance, with invariants enforced by database triggers. Accounting: business events turned into entries by rules, closable periods, depreciation and a cash-flow statement.
Knowledge base: 7,352 passages from four standards books in English and Russian, with hybrid keyword and embedding search and cross-language query expansion.

Result

Cross-language top-1 retrieval rose from 11/20 to 18/20 on the benchmark after query expansion.
Both layers pass their acceptance scenarios; answers cite page and clause.

What made it robust

110+ tests, including migration-downgrade tests.
Invariants live in the database, not only in application code.

Have a similar problem?

Tell me about it — I'll reply with an honest view of scope, approach and what a first milestone could look like.