Beyond traditional accounting: The financial ledger powering Tamara’s business

By Hashim Alsharif, Product Manager Ledger & Wallet

What is a Ledger

A ledger is a chronological, immutable record of financial events. It’s a historical log of what happened to every unit of currency in the system. It underpins trust, transparency, and compliance by enforcing traceability and accuracy in financial reporting.

Unlike a balance sheet which shows the current amount, a ledger logs how you got there. Every change, every cause, every time.

Why do financial institutions need a Ledger

Ledgers enable financial institutions to track money across products, legal entities, and geographies, maintain auditable records in line with accounting standards, generate timely and reliable financial reports, and efficiently reconcile payments, balances, and operations.

While some institutions choose to build their own ledger systems, many rely on off-the-shelf ERP platforms, core banking solutions, or outsourced infrastructure. These approaches can accelerate implementation but often come with trade-offs. Packaged systems may lack flexibility, offer limited product-specific controls, or struggle to adapt to evolving regulatory and operational needs. Building an in-house solution, though more complex, offers full ownership and customization over how financial events are modeled and recorded.

Why Tamara built its own Ledger

At Tamara, we chose to develop our ledger internally because the systems offered by core banking platforms didn’t meet the dynamic needs of our business. These platforms are often built for traditional institutions with simpler operations. Our setup spans multiple products, services, and regions, which requires more flexibility and control. We operate across different markets and business models, and financial data flows through many teams and services. That’s why we needed a Ledger robust enough to handle this level of complexity, especially as a buy now pay later payments provider.

Our decision to build our own foundational system was driven by the need to:

• Support Reliable and Scalable Financial Reporting: Ensuring accuracy and speed as we grow.

• Consolidate Financial Data: Bringing together information from all products, entities, and services into one unified view.

• Act as a Transactional ERP: Capturing both internal business expenses and granular, product-level transactions.

Owning this critical system empowers us to innovate faster, maintain consistency, and ensure complete trust in our financial operations as we continue to expand.

Consolidation layer: Our unified financial backbone

Our core systems, while excellent at their specific tasks, couldn't natively accommodate all our complex financial requirements. To address this, we introduced a dedicated ledger layer. This layer serves as the central hub for all financial events, working by aggregating entries from multiple disparate services. 

It simplifies integration for engineering teams by providing a streamlined interface to record financial activity, and crucially, it enforces accounting rules automatically, applying predefined rules to ensure financial consistency and compliance across the board.

Technical deep dive: The anatomy of Tamara's Ledger

To truly understand how our ledger operates, let's break down its key components:

• Legal Entity: Represents how financials are segregated. Each country where Tamara operates is isolated through its legal entity configuration, meeting specific regulatory and operational needs.

• Product: Each product (e.g., BNPL+, BNPL) is treated as a separate dimension, allowing financial analysis at a granular product level.

• GL Accounts (General Ledger Accounts): These are the fundamental records capturing financial transactions under specific categories like assets, liabilities, equity, revenue, or expenses. Every GL Account adheres to standard accounting principles.

• Operation: A high-level business process that groups together related monetary movements (e.g., a customer repayment operation).

• Monetary Movement: A detailed record of credits and debits tied to a specific business event.

• Journal Entry: The core system entry recording financial activity, containing links to the Product, Legal Entity, GL Accounts, and other critical metadata.

• Financial Operation Submission: A translation layer triggered by Tamara’s services. It abstracts the complexity, enabling services to record financial activity without needing direct knowledge of accounting practices.

• Accounting Rules: Predefined rules that map a financial transaction to a specific debit and credit GL Account pair. These rules ensure financial consistency and adherence to accounting standards.

Example: Memberships accounting rule

When a customer purchases a membership, the following accounting entry is recorded:

Debit: Unearned Revenue — recognizing the cash received but not yet earned.

Credit: Membership Revenue — as the service is provided, revenue is recognized progressively.

Our agnostic architecture supports both cash-based and accrual-based accounting models. The key difference lies in when a service triggers the ledger entry — either at the time of cash movement or as revenue is earned.

Account-level multi-currency view

Operating across multiple regions means handling multiple currencies seamlessly. Our ledger design excels here. To illustrate how the same GL account can surface in two currencies across two legal entities, consider Customer Receivable (ID 1201) under the BNPL+ product:

To show how the same GL account can surface in two currencies across two legal entities, let’s use Customer Receivable (ID 1201) under the BNPL+ product:

• April 10, 2025 – customer repayment of 1 000 SAR in Tamara KSA → Debit Customer Receivable (SAR)

• April 12, 2025 – customer repayment of 1 500 AED in Tamara UAE → Debit Customer Receivable (AED)

When you query account 1201 for April, the ledger returns two currency-specific rows:

You can further slice this data by operation, metadata or time window, but the key is that one account code returns multiple currency buckets across entities without any on-post conversion. This structure is essential for financial institutions operating e-commerce platforms across multiple regions.

Further drills

• Product → Currency → Legal Entity: view “Revenue (ID 4001)” to see AED entries under Memberships / UAE and SAR entries under Memberships / KSA.

• Cross-product: query “Unearned Revenue (ID 1101)” across all entities and products to see SAR, AED or other currencies side by side.

Understanding Balances: A "No-Balance" approach

One of the most misunderstood concepts for non-finance stakeholders is how balance tracking works in accounting systems. Specifically, the difference between running balances and no-balance approaches.

Our ledger follows a no-balance design. This means we don’t store real-time balances at the account level. Instead, balances are derived on demand by summing up all transactions (journal entries) within a defined time window. The ledger remains the immutable source of truth, and balance is always a result, not a state.

To calculate balances, we rely on two parameters:

• period_start: The beginning of the reporting window

• period_end: The end of the reporting window

Within this period, we compute the signed amounts for each account using standard accounting rules. For example, assets and expenses normally carry a debit balance. Liabilities, equity, and income normally carry a credit balance:

Submission samples

{ "orderId": "an_order_id21", "operationReference": "pay_12343712234", "legalEntityId": 1, "productId": 1, "operationCode": 1, "monetaryMovements": [ { "movementCode": 1, "money": { "amount": 500, "currency": "AED" } } ], "additionalData": { **Metadata** array } }

Submission translation

Once the submission is processed, it’s translated into journal entries by applying the relevant accounting rule. Here's how the system interprets the submission and maps it to a ledger entry:

Once this submission is processed, it's translated into journal entries by applying the relevant accounting rule. This transformation is fully deterministic, based on:

• The operationCode, which links to an Accounting Rule

• The monetaryMovements, which define the amount and currency

• The legalEntityId and productId, which provide context for segmentation

• The Sign, which defines whether the transaction is a credit or debit

• The additionalData, passed through as metadata for audit and traceability

Outcome and impact

The ledger now acts as a real-time financial source of truth across Tamara. It provides traceable, auditable entries that support reconciliation, reporting, and analytics for all of our product suites.

Since launch, teams across product, finance, and engineering have been able to close books faster with confidence in the underlying data, scale new financial products without needing to redesign the ledger, and maintain clear accountability and traceability for every financial event.

This design ensures that Tamara’s financial systems can scale with growing complexity while maintaining strict compliance and auditability, a critical advantage in the fast-paced world of BNPL and fintech innovation.