Internal balances

​

Overview

In your application, there are scenarios when your balances interact with your organization accounts or external balances. As a principle, it is crucial for you to have an organized way of tracking these interactions (read: transactions) in your ledger.

This is why Blnk created the “General Ledger.” The general ledger like every other ledger in your Blnk server also contains balances that participate in transactions.

But the main difference between the general ledger and other ledgers is that it is meant to group balances owned by your internal business operations. We refer to these balances as “Internal balances.”

In this guide, we’re going to learn about internal balances, what they are, and how to create them in your Blnk ledger.

​

What is an internal balance?

An internal balance is a ledger balance owned by your organization, e.g., revenue, fees, loans, etc. You can use an internal balance to track interactions between your own accounts as an organization and your application.

For instance, you own an online e-commerce app that assigns a wallet to every signed up user. Two things happen:

• Every time a user pays for something on your app with their wallet, their balance is debited and you earn revenue.
• Every time a user funds their wallet, a fee is debited from the user’s wallet and paid somewhere (the e-commerce startup or the payment processor).

There are two destinations that have not been defined — revenue and fees. These have to be represented as balances held and managed by the organization.

To do this, you need to create these balances in the General Ledger and provide them as the destination in your transaction record request to complete the transaction.

​

Creating an internal balance

Blnk makes this simple by automating the creation and identity of balances in the general ledger. When a transaction is recorded and a balance is referenced using the ”@” prefix, Blnk checks to see if it exists in the General Ledger.

If the specified balance doesn’t exist, it is automatically created, and the transaction is processed accordingly.

Continuing our earlier example, we can represent revenue with @Revenue and fees with @Fees. A transaction request from the user’s wallet when they pay for something on the app would look like this:

{
    "amount": 750000,
    "reference": "ref_1298122819291982",
    "currency": "USD",
    "precision": 100,
    "source": "bal_91283-8102dj1-1209212-129109",
    "destination": "@Revenue"
}

Important to note:

When you post a transaction to a new internal balance, the balance is created with the same asset class specified in the transaction, e.g., in the example above, @Revenue is a USD internal balance.

​

Naming conventions

When choosing names for your internal balances, it’s important to use consistent and descriptive naming schemes. This ensures easy recall and reduces the risk of errors when posting transactions.

Here are some things to note when naming your internal balances:

1. Always use the @ prefix to automatically add it to the General Ledger.
2. Use names that clearly describe the balance’s purpose, e.g., @Revenue, @Fees, @World, etc.
3. You can use the same name for balances that perform the same function, but for different asset classes, i.e., you can have two balances named @Revenue but one is in EUR, while the other is in USD.
4. Use camel case (@OnlineRevenue) or underscores (@online_revenue) to separate words for better readability. Avoid including spaces to prevent formatting issues.
5. Keep it short to facilitate easier referencing.

​

Representing external balances

When balances interact with external balances like other bank accounts, wallets, cards, etc., it is still required that the corresponding entry is recorded in your ledger.

To do this, create a new internal balance called "@World" and use it to represent all interactions with the outside world. You can also choose to name it however you want, as long as it represents all interactions with the outside world in your ledger.

See the table below for a simplified example of how @World works.

When using the @World balance in a transaction, it is encouraged to enable overdrafts. This allows you to be able to record transactions on @World even when its balance is less than 0. A negative balance on @World means your application has received more money than it has sent out, and vice versa.

To learn more about how to use @World, read our guides on Money movement and Ledger architecture.

​

See also

​

Need help?

Are you stuck? Do you have a question that isn’t answered in this doc? Have you run into a problem you can’t solve? Want to file a bug report?

Join our Discord server and share your questions/thoughts with other developers building financial applications like you.