Introduction

If you’ve read any part of the Blnk documentation, you must have heard about the Double Entry Accounting principle.

It is a big deal in the business world of accounting today. Every business, small, medium or large, relies on this simple principle to do accurate bookkeeping and reconciliation of their books.

For financial applications, it means keeping the books of an organization across multiple nodes in your system. As a software engineer or technical founder, this can be very new territory for you, and it is even more daunting when you have to build a financial application. Don’t worry! Thousands of others like you across the world also face this problem.

The Double Entry Accounting principle

The Double Entry Accounting principle states that for every entry into an account, there needs to be a corresponding and opposite entry into a different account.

Only two types of entries can happen an account — a credit and a debit. When an account is credited, money is added to the account, and when it is debited, money is removed from the account. So the principle states that if there’s a credit entry in one account, there must be an equal debit entry in another account. Another way to visualize the Double Entry principle is that for every transaction, there must be a source and a destination.

Part 1: The Basics

There are two rules to the double-entry principle:

1. Every financial category in your organization is represented by an account.
2. Every financial transaction can be modeled as a “transfer” between accounts.

For example, let’s say User A has $5,000 in their account and they pay the company $3,000. If we tracked only the company’s accounts, we see only a $3,000 credit with no information on where it came from, and that’s not true — it moved from User A to the company’s account.

So the records look like:‍

The payment is entered twice (hence, “double” entry); it is removed from User A and added to the company account. The amount inputed on both accounts must always be equal, so that no value is lost — it’s just been moved around.

Why is it important for the value to be equal? Because the double entry aims to be the source of truth for your financial records. When you say you received $3,000, the assumption is that someone else paid $3,000 to you. If you received $3,000 despite being paid $4,000, it becomes a case of fraud and dishonesty which is terrible for any business

Let's build it with Blnk

Let’s model this on our Blnk server.

1. Create a new ledger

First, we create a new ledger to group our balances in, and we’ll name it “User Balances”. To do this call the endpoint URL, /ledgers, and pass the following in its request body:

1{
2    "name": "User balances",
3    "meta_data": {
4        "project_owner": "Blnk Finance"
5    }
6}

Copy the ledger_id from the response. You’ll need it for the next step.‍

2. Create a balance for User A in the ledger you've just created‍

Next, create a balance for the user.

To do this, call the endpoint URL, /balances, and pass the following in its request body:

{
    "ledger_id": "ldg_073f7ffe-9dfd-42ce-aa50-d1dca1788adc",
    "currency": "USD"
}

Copy the balance_id from the response. You’ll need it for the next step.
‍

3. Record the transaction between the user and your company

To do this, call the endpoint URL, /transactions, and pass the following in its request body:

{
    "reference": "ref_8728781718",
    "amount": 3000,
    "currency": "USD",
    "precision": 100,
    "source": "bln_ebcd230f-6265-4d4a-a4ca-45974c47f746",
    "destination": "@CompanyRevenue",
    "description": "Invoice payment",
    "meta_data": {
        "user_id": "user_a"
    }
}

This moves 3000 from User A’s balance to your revenue account (represented by an internal balance in your ledger).

4. Here's how the transaction records look like

You can see at first glance that this transaction has a source (where it was debited from) and a destination (where it was credited to).

The amount was converted to its lowest unit (cents, in this case) to ensure correctness when computing the balances. To learn more, read: Understanding precision.

Part 2: Dealing with the real world

Dealing with double entry when you manage both accounts is easy. But what happens when you deal with the world? What happens if User A sends the same $3,000 to an external bank account outside of our system? How do we represent it with the double entry principle?

To do this with Blnk, we recommend that you create an internal balance to represent all transactions with with the outside world. We call it "@World". This way you can track all money in and out of your system from one balance.

To apply it, use @World in the source or destination field depending on what kind of transaction it is, and you now have a corresponding, traceable entry equal to your user balance’s entry. For example, User A sent money out, your transaction records would look like this:

Applying this to your financial application

When building your financial application, it is important to apply the double entry principle to ensure that you can guard against fraud and dishonesty. Blnk allows you to be able to see both entries in one record, instead of recording the CR and DR entries in separate records in your database.

Good financial recording also saves you a lot of time and effort in performing settlements and reconciliation, a necessary operation for any financial application in today’s world.

With Blnk, you don’t have to worry about building the structures for Double Entry recording. You have instant access to all the tools you need to correctly record and track all transactions in your application.

‍