This post explores mapping traditional debits and credits onto a source/destination ledger. We'll first examine the emergence of the credit/debit system, focusing on the necessity of different account types and how debits and credits uniquely affect account balances. Then, we'll apply these concepts to a source-destination model, demonstrating their relevance in a modern fintech app.

At nxos, we're building as-simple-as-possible, scalable fintech infrastructure. Our focus includes ledgers, reconciliation, card integrations, and, in particular, cross-border payments.

Needless to say, if your company needs fintech solutions in ledgers, reconciliation, card integrations, or cross-border payments, reach out to me at [email protected] to explore how nxos can help.

Part 1: The Need for Account Types: Origins and Purpose

Before we jump into accounting practices, a key piece of historical context is: Venetian accountants, who in the 15th century invented modern accounting, were unaware of negative numbers. Despite negative numbers' use in Chinese and Indian mathematics for centuries, they weren't ubiquitous in Europe until much later in the 18th and 19th centuries. This limitation forced Venetian accountants to design a system that tracked all money flows without using negative amounts.

Designing a closed-loop payment system without negative numbers is challenging. Imagine Day Zero: five Venetian merchants, no money created or transacted, all balances at zero. How do we represent their first trade?

At its core, money flows for goods and services, always having a source and a destination. When a Venetian merchant purchases silk, they give money and receive silk in return. This principle underlies Venetian double-entry bookkeeping: one entry for money's origin, one for its destination.

Consequently, Our Venetian merchants and their accountants face two key constraints:

An intuitive solution is a source/destination model, but it fails without negative numbers. If everyone starts at zero and merchant_a sends merchant_b 10 Lira, merchant_a's balance would become -10 Lira, which Venetians couldn't express. Instead, we create two columns: outgoing and incoming. When merchant_a sends 10 Lira to merchant_b:

merchant_a:

outgoing incoming
10 Lira 0 Lira

merchant_b:

outgoing incoming
0 Lira 10 Lira