Мне кажется, основная проблема этой дискуссии в недопонимании причин обозначенного в теме предложения.
Идея ведь совсем не в том, чтобы изобрести новый бухучет. А просто в том, чтобы несколько упростить работу с программой.
 
На том же самом примере с кабаком и такси.
Утром проснувшись пересчитал деньги в кошельке и внес в AC операцию за 26.02.2006 10:00 с типом остаток и соотв. значением. Деньги в кошельке - это объективная реальность. И после ввода этого остатака программа эту реальность адекватно отражает. Уже хорошо. (При этом я, как минимум, немного сэкономил на простоте ввода: вместо выражения типа <предыдущий остаток> - <текущий остаток> я просто ввел значение остатка на данный момент - посчитать разность программа может и сама.)
Далее. Если на следующий день (через неделю, через месяц) я вспомнил, что возвращался из кабака на такси (и для меня, например, важно это уточнение), я просто введу операцию расхода за 26.02.2006 03:00 с суммой, потраченной на такси. И все! Остаток на момент времени 26.02.2006 10:00 останется неизменным! Именно тем, который я тогда насчитал в кошельке. Соответственно, все последующие операции не "поедут".
Без наличия же типа операций "остаток" мне придется, как минимум, еще отыскать ту операцию "кабак" и откорректировать ее сумму на соответствующую величину. Т.е. приложить дополнительные усилия, которых вполне можно было бы избежать.
 
Т.е., другими словами, в отличие от прихода/расхода/перевода, которые фиксируют сумму операции и на ее основании вычисляют текущее значение баланса, операция типа "остаток" наоборот фиксирует именно значение баланса и на его основании вычисляет сумму операции.
Очевидно также, к операции "остаток" неприменимы классификаторы. У нее не может быть статьи или агента.
 
А в будущем, для анализа можно было бы сделать фильтр для поиска операций "остаток" с суммой получившейся больше заданного порога. Но это к слову.