From code lines to the double-entry accounting

Why fintech software engineers should learn and embrace the double-entry accounting system?
From code lines to the double-entry accounting

Furthermore, would you believe if I said that it’s possible to manage the state of an object in software engineering using a financial accounting system?

As I write this article, two years have passed since I joined Moneyflow A/S as a software engineer. This company provides embedded financing services, specifically invoice factoring. It is ok if these terms don’t ring a bell.

Embedded financing, invoice factoring

Let me (try to) explain it. Imagine your company issues an invoice to a customer using an ERP (Enterprise Resource Planning) system. Normally, you’d have to wait for the customer to pay the invoice, which could take days, weeks or even months.

But if your business requires immediate liquidity (a.k.a. cash), you can opt to sell the invoice directly to Moneyflow from the ERP system for a small fee (of course). And within a few hours, the money (invoice amount minus the fee) will be deposited into your bank account.

From definition, breakdown:

  • Embedded financing - integrated financial services into an app.
  • Factoring - financial transaction in which a business sells its accounts receivable (a.k.a invoices) to a third party.

Probably, I had to start with the definition first :) Back to the studio…

Factoring system’s flow & requirements

In other words, you can say that the factoring system lives under the hood (is embedded) of an accounting system. Whenever a new invoice is issued the factoring system:

  1. Does some heavy risk assessments (validate involved parties, historical data analyses, fraud risks, etc.)
  2. If all is good, the system automagically generates an offer to the client.
  3. And if the offer is accepted, the system purchases the invoice and disburses the funds.

In this article, we are focusing on the last part - financial accounting, which heavily relies on:

  • Consistency: Internal records should align precisely with actual bank statements.
  • Reliable reconciliation engine: Ensuring that all transactions are accurately matched and accounted for.
  • Balanced accounts: Ensuring that balances make sense based on a set of transactions.
  • Robust payout system: Making sure we pay out what was agreed on (not more, not less).
  • Being in a good relationship with the accountants: Accounting has been done correctly.

Luckily, dependable financial systems that address the challenges mentioned above existed far longer than the Gang of Four (design patterns).

Double-entry accounting to the rescue

Dating back to 1494, the system of double-entry accounting has stood the test of time, so there is no need to reinvent the wheel here. Learning double-entry accounting was also one of the greatest skills I’ve picked up during the past two years (thank you Mathias and Alexander).

For simplicity’s sake, I will skip the “how it works” part and get strict to the points on why the double-entry accounting system is reliable:

1. Being able to trace back the money trail

Each transaction has its source and destination. Meaning, it has at least two entries, each of which corresponds to one account. One account represents the source (credit) and the other represents the use of funds (debit). In other words, you can trace back where the money came from and where it went.

2. Account balance represents a state

A single account reflects a specific aspect of the company’s financial position or transaction history. By examining an account’s balance (sum of transaction entries), you can discern the state of the current asset.

For example, in the context of invoice factoring, you can check if the invoice has been paid back:

receivables_balance = Transactions(

if receivables_balance > 0:
elif receivables_balance == 0:
elif receivables_balance < 0:
   print("paid_back, handle_overpaid_balance")

3. Ensures the accuracy and integrity of financial records

Since the system ensures that every financial entry (a subset of the transaction) is recorded twice. Once as debit and once as credit. And on top of that you also have to check if the entries are balanced: sum(debit) == sum(credit). This makes it easier for errors or discrepancies to be noticed.

4. Scalability

Using double-entry bookkeeping eliminates the need for complex state machines. It simplifies maintenance, even with new features, making it a robust framework for managing state in financial applications. If there is a need for a new state, consider creating a new account in the flow.

Actions speak louder than words

Over the past two years, with the help of the double-entry accounting system, I was able to:

  • Develop comprehensive bank reports, which surprisingly was my initial task, evolving into a six-month epic.
  • Design and execute collateral withholding and payout processes (including bookings on 3rd party ERP systems),
  • Enhance internal cross-asset balance transfers, often solving complex issues with simple solutions by introducing additional accounts.
  • Being aligned with the company’s accountant.

Applying double-entry accounting beyond finance

I believe the double-entry accounting system should be used whenever your system involves currency. For example, in video games, you could use the system to:

  • Balance the tap & sink flow, ensuring a stable in-game economy.
  • Managing players’ assets and conducting behaviour analysis.
  • Detect cheating attempts just by looking at the ledger.


Just because you are a software engineer doesn’t mean that you have to use only software architecture design patterns. Don’t be afraid to look out for systems that have existed long before computers.

If you feel adventurous, here are some good articles, and videos on how exactly financial accounting works: