How to Calculate Balances in an Accounting Software Using Postgres Window Function

how to calculate balances in an accounting software using postgres window function

select t.*, sum("In"-"Out") over(order by id) as balance
from tbl t
order by id

Fiddle: http://sqlfiddle.com/#!15/97dc5/2/0

Consider changing your column names "In" / "Out" so that you don't need to put them in quotes. (They are reserved words)

If you wanted only one customer (customer_id = 2):

select t.*, sum("In"-"Out") over(order by id) as balance
from tbl t
where customer_id = 2
order by id

If your query were to span multiple customers and you wanted a running balance that RESTARTED with each customer, you could use:

select t.*, sum("In"-"Out") over( partition by customer_id
                                  order by customer_id, id ) as balance_by_cust
from tbl t
order by customer_id, id

how to cause a trigger to calculate balances in an accounting software using postgres

This is actually harder than it looks.

More than one person might concurrently be inserting a row, and their commit orders might not be the same as the order in which the rows are created. That means that a trigger calculating the balance won't see rows it should and the balance will be wrong.

To make this work reliably, you must LOCK TABLE ... IN EXCLUSIVE MODE before doing an INSERT, or you must use SERIALIZABLE isolation in 9.2 or newer. Both introduce the need to re-try failed transactions:

SERIALIZABLE will abort a problematic transaction and force you to re-try it; and
Taking a lock in a trigger involves a lock upgrade, which can deadlock, causing the transaction to be aborted.

so your app must be prepared to re-try failed transactions.

To avoid this you can use READ COMMITTED isolation and have the app explicitly LOCK TABLE ... IN EXCLUSIVE MODE the table of interest before it tries to do anything else with it, even SELECT from it, if it thinks it might later need to INSERT a row into it. However, concurrency will then suck somewhat.

So, given that, you'd write something like:

CREATE OR REPLACE FUNCTION balance_insert_trigger() 
RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN 
    -- This can deadlock unless you already took the lock earlier
    -- in the transaction; we put it here only for safety to make
    -- sure to block concurrent inserts.
    LOCK TABLE mytable IN EXCLUSIVE MODE;

    IF tg_op = 'INSERT' THEN
        NEW.balance = (SELECT sum(in) - sum(out) FROM mytable);
        RETURN NEW
    ELSE
        -- It's not safe to DELETE FROM or UPDATE this table because of the
        -- running balance.
        RAISE EXCEPTION '% operation not permitted on this table', tg_op;
    END IF;
END;
$$;

CREATE TRIGGER balance_insert_trigger
BEFORE INSERT OR UPDATE OR DELETE ON mytable 
FOR EACH ROW EXECUTE PROCEDURE balance_insert_trigger();

then always:

BEGIN;
LOCK TABLE mytable IN EXCLUSIVE MODE;
INSERT INTO mytable ...;
COMMIT;

If you want to support UPDATE and DELETE too, then things get exciting.

Calculate balance with mysql

Short answer, yes

Longer answer, you can use a variable to tally it up as it iterates down the rows, i.e.

SELECT 
    `table`.`ID`,
    `table`.`In`,
    `table`.`Out`,
    @Balance := @Balance + `table`.`In` - `table`.`Out` AS `Balance`
FROM `table`, (SELECT @Balance := 0) AS variableInit
ORDER BY `table`.`ID` ASC

The , (SELECT @Balance := 0) AS variableInit ensures that @Balance is initialised to 0 before you start. For each row it then sets @Balance to be @Balance + In - Out, and then outputs the calculated value.

Also it's worth making certain the ORDER is consistent as otherwise the Balance will vary depending on what order the rows are returned. If you wanted to then order it back to front, for example, you could use this as a subquery as then the outer query deals with the calculated values thus ensuring the Balance remains correct i.e.

SELECT
    `balanceCalculation`.`ID`,
    `balanceCalculation`.`In`,
    `balanceCalculation`.`Out`,
    `balanceCalculation`.`Balance`
FROM (
    SELECT 
        `table`.`ID`,
        `table`.`In`,
        `table`.`Out`,
        @Balance := @Balance + `table`.`In` - `table`.`Out` AS `Balance`
    FROM `table`, (SELECT @Balance := 0) AS variableInit
    ORDER BY `table`.`ID` ASC
) AS `balanceCalculation`
ORDER BY `balanceCalculation`.`ID` DESC

Relational Data Model for Double-Entry Accounting

A. Preliminary

Your Approach

First and foremost, I must commend your attitude. It is rare to find someone who not only thinks and works from a solid grounding, and who wishes to understand and implement a Double-Entry Accounting system, instead of:

either not implementing DEA, thus suffering multiple re-writes, and pain at each increment, each new requirement,
or implementing DEA, but re-inventing the wheel from scratch, by figuring it out for oneself, and suffering the pain at each exposure of error, and the demanded bug fixes, a sequence that never ends.

To avoid all that, and to seek the standard Method, is highly commended.

Further, you want that in the form of a Relational data model, you are not enslaved by the Date; Darwen; Fagin; et al views that prescribes a Record ID based Record Filing Systems, that cripples both the modelling exercise and the resulting "database". These days, some people are obsessed with primitive RFS and suppress Dr E F Codd's Relational Model.

1. Approach for the Answer

If you do not mind, I will explain things from the top, in logical order, so that I can avoid repeats, rather than just answering your particular requests. I apologise if you have complete knowledge of any of these points.

Obstacle

Ideally I would like to see what those double entry rows look like in database terms

That is an obstacle to the proper approach that is required for modelling or defining anything.

In the same way that stamping an ID field on every file, and making it the "key", cripples the modelling exercise, because it prevents analysis of the data (what the thing that the data represents actually is), expecting two rows for a Credit/Debit pair at the start will cripple the understanding of what the thing is; what the accounting actions are; what effect those actions have; and most important, how the data will be modelled. Particularly when one is learning.

^{Aristotle teaches us that:}
^{the least initial deviation from the truth is multiplied later a thousandfold ...}
^{a principle is great, rather in power, than in extent; hence that which was small [mistake] at the start turns out a giant [mistake] at the end.}

Paraphrased as, a small mistake at the beginning (eg. principles; definitions) turns out to be a large mistake at the end.

Therefore the intellectual requirement, the first thing, is to clear your mind regarding what it will be at the end of the modelling exercise. Of course, that is also required when one is learning what it is, in accounting terms.

2. Scope for the Answer

Assume there is a bank, a large shop, etc, that wants the accounting to be done correctly, for both internal accounts, and keeping track of customer accounts.

Let's just call it System instead of Bank, Bank may be too complex to model ...

Customers perform a set of operations with system (deposits, withdrawals, fee for latter, batch fees), and with each other (transfer).

To be clear, I have determined the scope to be as follows. Please correct me if it is not:

Not a small business with a General Ledger only, with no Customer Accounts
But a small community Bank, with no branches (the head office is the branch)
You want both the internal Accounts, which consists of:
a simple General Ledger,
as well as external Accounts, one for each Customer
The best concept that I have in mind is a small community Bank, or a business that operates like one. An agricultural cooperative, where each farmer has an Account that he purchases against, and is billed and paid monthly, and the cooperative operates like a small bank, with a full General Ledger, and offers some simple bank facilities.
A single Casino (not a chain) has the same requirement.
Not a large Bank with multiple branches; various financial products; etc.
Instead of System or Bank, I will call it House. The relevance of that will be clear later.

Anyone seeking the Double-Entry method for just the Ledger, without the external Customer Account, can glean that easily from this Answer.

In the same vein, the data model given here is easy to expand, the Ledger can be larger than the simple one given.

B. Solution

1. Double-Entry Accounting

1.1. Concept

To know what that it is by name; that it has great value; that it is better than a roll-your-own system, is one thing, knowing what it is deeply enough to implement it, is another.

First, one needs to have a decent understanding of a General Ledger, and general Accounting principles.
Second, understand the concept that money represents value. Value cannot be created or destroyed, it can only be moved. From one bucket in the accounts to another bucket, otherwise known as Debit (the from-account) and Credit (the to-account).
While it is true that the SUM( all Credits ) = SUM( all Debits ), and one can obtain such a report from a DEA system, that is not the understanding required for implementation, that is just one end result. There is more to it.

While it is true that every transaction consists of a pair: one Credit and one Debit for the same amount, there is more to that as well.
Each leg of the pair; the Credit and Debit, is not in the same Account or Ledger, they are in different Accounts, or Ledgers, or Accounts-and-Ledgers.
The SUM( all Credits ) is not simple, because they are in those different places (sets). They are not in two rows in the same table (they could be, more later). Likewise, the SUM( all Debits ).
Thus each of the two SUM()s cover quite different sets (Relational Sets), and have to be obtained first, before the two SUM()s can be compared.

1.2. Understanding Double-Entry Accounting

Before attempting a DEA implementation, we need to understand the thing that we are implementing, properly. I advise the following:

You are right, the first principle is to hold the perspective of the Credit/Debit Pair, when dealing with anything in the books, the General Ledger; the Customer Accounts; the bank Accounts; etc.

This is the overarching mindset to hold, separate to whatever needs to be done in this or that Account or Ledger.
I have positioned it at the top; left, in the data model, such that the subordination of all articles to it is rendered visually.

The purpose or goal of a Double-Entry Accounting system is:

Eliminate (not just reduce) what is known as:
- "lost" money
- "lost" Transactions (one or the other side of the Credit/Debit pair)
- and the time wasted in chasing it down.
- Not only can money be found easily, but exactly what happened to it, and where it is now, can be determined quickly.
Full Audit functionality

It is not good enough to keep good Accounts, it is imperative for a business that accounts for other people's money, to be readily audit-able. That is, any accountant or auditor must be able to examine the books without let or hindrance.
- This is why the first thing an outsider, eg. an auditor, wants to know is, does the SUM( all Credits ) = SUM( all Debits ). This also explains why the DEA concept is above any Accounts or accounting system that the company may be keeping.
The great benefit, although tertiary, is that the everyday or month end tasks, such as a Trial Balance or closing the books, can be closed easily and quickly. All reports; Statements; Balance Sheets; etc, can be obtained simply (and with a single SELECT if the database is Relation).

Then ready the Wikipedia entry for Double-Entry Bookkeeping.

The internet has plenty of misleading information, and Wikipedia is particularly awful that is forever changing (truth does not change, falsity changes with the weather), but sorry, that is all we have. Use it only to obtain an overview, it has no structural or logical descriptions, despite its length. Follow the links for better info.
I do not entirely agree with the terminology in the Wikipedia article. Nevertheless, in order to avoid avoidable confusion, I will use those terms.
There are tutorials available on the web, some better than others. These are recommended for anyone who is implementing a proper Accounting system, with or without DEA. That takes time, it is not relevant to an answer such as this, and that is why I have linked the Wikipedia article.

2. Business Transaction

Ideally I would like to see what ~~those~~ double entry ~~rows~~ looks like in database terms, what the whole process will look like in SQL, which entities are affected in each case, etc.

Ok. Let's go with the Transactions first, then build up to understanding the data model that supports them, then inspect the example rows. Any other order would be counter-productive, and cause unnecessary back-and-forth.

Your numbering. Green is House in the General Ledger, blue is external Customer Account, black is neutral.

This is the first increment of Treatment, how a thing is treated, in different scenarios (your concern, and your request for specific examples, is precisely correct).
Credit/Debit Pairs

This is the first principle of DEA, understand the pair, as the pair, and nothing but the pair.

Do not worry about how the General Ledger or the Account is set up, or what the data model looks like. Think in terms of an accountant (what has to be done in the books), not in terms of a developer (what has to be done in the system).

Notice that the each leg of the pair is in the one set (the Ledger), or in two sets (one leg in the Ledger, the other leg in Account). There are no pairs in which both legs are in Account.

Because DEA is implemented, each Business Transaction (as distinct from a database Transaction), consists of two actions, one for each Credit/Debit leg. The two actions are two entries in a paper-based account book.

A Client deposits cash to his account

Op11
Op12

During the DayEnd procedure, among other tasks, all cash is accounted for and checked. The day is closed. All cash sitting in HouseCash that is beyond whatever the bank deems necessary for everyday cash Transactions, is moved to HouseReserve.

Op13

The Bank charges fees once a month to all Clients accounts (sample batch job)

Op2

This charges each Account with the Fee
Fee is dependent on AccountType_Ext
This is the simple case. If the Fee is dependent on something else, such as the number of transactions in the Account; or the CurrentBalance being below or above some limit; etc, that is not shown. I am sure you can figure that out.

A Client does some operation over the counter, and the Bank charges a fee (cash withdrawal + withdrawal fee),

Simple Transactions do not incur fees, and Deposit/Withdrawal has already been given. Let's examine a business Transaction that actually attracts a fee.

Op3

Mary sends $500 USD to her son Fred, who is travelling overseas looking for whales to save, and has run out of money. The bank charges $30 for an Overseas Bank Transfer. Fred can collect the funds (in local currency equivalent of $500 USD) at any partner bank branch.
To actually transfer the money to the foreign bank, the House has to interact with a local big bank that provides international settlement and currency exchange services. That is not relevant to us, and not shown. In any case, all those types of Interbank transactions are batched and dealt with once per day, not once per AccountTransaction.
In this simple DEA system, the House does not have currency accounts in the Ledger. That is easy enough to implement.

Mary sends some money from her account, to John's account, which is in the same bank

Op4

The money is currently in Mary's account (deposited on a day prior to today), that is why it is in HouseReserve, not HouseCash
The money is moved from HouseReserve into HouseCash because John may come into the bank today and withdraw it.
As described in example [1.3] above, at the DayEnd procedure, any money sitting in HouseCash in all Accounts will be moved to HouseReserve. Not shown.

3. Relational Data Model • Initial

Now let's see what the data modeller has done, to support the accountant's needs, the business Transactions.

This is of course, the second increment of Treatment, what the modeller has understood the real world business Transactions to be, expressed in Relational terms (FOPC; RM; Logic; Normalisation)
This is not the simplest data model that is required to satisfy the restated scope.
There are simpler models (more later), but they have problems that this one does not have, problems that are desirable, if not imperative, to avoid.
The image is too large for in-line viewing. Open the image in a new tab, to appreciate it in full size.

3.1. Notation

All my data models are rendered in IDEF1X, the Standard for modelling Relational databases since 1993.
My IDEF1X Introduction is essential reading for those who are new to the Relational Model, or its modelling method. Note that IDEF1X models are rich in detail and precision, showing all required details, whereas home-grown models, being unaware of the imperatives of the Standard, have far less definition. Which means, the notation needs to be fully understood.

3.2. Content

The main difference between a genuine Relational data model produced by someone else, and mine, is:

a business Transaction (always two actions; two legs, one per Credit/Debit) is affected by a single row with two sides, one per Credit/Debit,

in AccountTransaction or LedgerTransaction.
Most modellers will model two rows for the Credit/Debit pair, one for each leg or side (hey, one leg is a Credit, and the other leg is a Debit, if I Normalise that, I get two rows).
Wrong. If I tell you that Fred is Sally's father, you know, from that single Fact, that Sally is Fred's daughter.
A FOREIGN KEY needs to be declared just once, not once for each side.
Likewise, the Credit/Debit pair is a single Business Transaction,

a single Atomic article, that can be perceived from either Side, like two sides of one coin. Modelled as such.
All manner of preventable bugs are prevented, the search for the "missing" leg is eliminated.
Even for those with sub-standard OLTP code, which causes quite preventable concurrency problems, if this method is implemented, this is one article wherein those problems will not arise.
Further, the number of rows in the %Transaction tables is halved.
I have arranged the articles such that the

External Account

Internal Ledger and LedgerTransaction

Internal-External AccountTransaction

are clear.
Along with a nugget of definition from the Wikipedia entry.
Having familiarised yourself with the DEA Credit/Debit pairs, now study the Treatment of the pair. Notice that the Treatment is different, it is based on a number of criteria (three account types; six Ledger types; etc), which in turn is based on the complexity of the General Ledger.
This Ledger is simple, with Asset/Liability accounts only. Of course, you are free to expand that.
The eagle-eyed will notice that AccountStatement.ClosingBalance and LedgerStatement.ClosingBalance can actually be derived, and thus (on the face of it), should not be stored. However, these are published figures, eg. the Monthly Bank Statement for each Account, and thus subject to Audit, and therefore it must be stored.

For a full treatment of that issue, including considerations; definition; treatment, refer to this Q & A:

Derived account balance vs stored account balance for a simple bank account?

3.3. Summary

In closing this section, we should have reached this understanding:

The overarching principle of DEA, the Credit/Debit pairs, purely intellectual
The typical business Transactions, always a Credit/Debit pair, two legs, two entries in the accounting books
A deeper understanding of the Treatment of said Transactions
The environment that the House (small bank; cooperative; casino) manages (internal Ledger and external customer Account)
A first look at a data model that is proposed to handle all that.

4. Relational Data Model • Full

Here it is again, with a full set of sample data.

Re the Primary Keys:
Note that LedgerNo and AccountNo are not surrogates, they have meaning for the organisation, in ordering and structuring the Ledger, etc. They are stable numbers, not an AUTOINCREMENT or IDENTITY or anything of the sort.
The Primary Keys for LedgerTransaction and AccountTransaction are pure, composite Relational Keys.
It is not a Transaction Number of some kind that is beloved of paper-based accountants.
It is not a crippling Record ID either.
The Alternate Keys are more meaningful to humans, hence I have used them in the examples (Business Transactions, above [2], and below [5]). This Answer is already layered, it would be a nightmare trying to relate hundreds of 1's, 2's and 3’s to each other.
If we wish to understand what something means, we need to hold onto the meaning that exists in the thing, rather than excising the meaning by giving it a number.
In the example data, the Primary Keys are bold.

TAdata

5. Business Transaction with Row

Ideally I would like to see what ~~those~~ double entry ~~rows~~ looks like in database terms, what the whole process will look like in SQL, which entities are affected in each case, etc.

Now that we understand the Business Transactions, and the data model that services the requirement, we can examine the Business Transactions along with affected rows.

Each Business Transaction, in DEA terms, has two legs, two entries in the paper-based account books, for each of the Credit/Debit pair,

is yet a single Business Transaction, and now:

it is affected by a single row with two sides, for each of the Credit/Debit pair.
This is the third increment in understanding Treatment: the business Transactions; data model to implement them; and now, the affected rows
The example database rows are prefixed with the table name in short form.

Plus means INSERT

Minus means DELETE

Equal means UPDATE.

A Client deposits cash to his account

Row11
Row12
Row13

The Bank charges fees once a month to all Clients accounts (sample batch job)

Row2

This, too, is a batch job, just one task in the MonthEnd procedure.
Notice the date is the first day of the month.

A Client does some operation over the counter, and the Bank charges a fee (cash withdrawal + withdrawal fee),

Row3

To be clear, that is three Business Transactions; two entries each, one for each side of the Credit/Debit pair; affected by one database row each.

Mary sends some money from her account, to John's account, which is in the same bank

Row4

6. SQL Code

There are usually several ways to skin a cat (code), but very few if the cat is alive (code for a high concurrency system).

The Relational Model is founded on First Order Predicate Calculus (aka First Order Logic), all definitions (DDL) and thus all queries (DML) are entirely Logical.
A data model that conforms to that understanding, is therefore entirely Logical.
The queries against such a data model are dead easy: Logical and straight-forward. They have none of the convoluted code that is required for Record ID based filing systems.

Therefore, out of the several methods that are possible for the SQL code requests, I give the most direct and logical.

^{The code examples are that which is appropriate for SO, it is imperative that you trap and recover from errors; that you do not attempt anything that will fail (check the validity of the action before using a verb), and follow OLTP Standards for ACID Transactions, etc. The example code given here are the relevant snippets only.}

6.1. SQL View • Account Current Balance

Since this code segment gets used in many places, let's do the right thing and create a View.

Note that on genuine SQL platforms, source code is compiled and run when it is submitted, Stored Procs and Views are stored in their compiled form, thus eliminating the compilation on every execution. Unlike the mickey mouse NONsql suites.
High-end commercial SQL platforms do a lot more, such as caching the Query Plans for Views, and the queries in Stored Procs.

How to Calculate Balances in an Accounting Software Using Postgres Window Function