принцип разумной достаточности во главу угла...
 
В реале организовывать "целые деревья операций и счетов" пожалуй не придется. В случае со счетами - это группировкапо признаку на одном уровне, группировки более обобщенные возможны на уровне разделения баз данных (например), пожалуй в пределах одной базы глубокие вложения счетов - излишество не оправданое...
В случае с операциями - это детализация операции на одном уровне вложения, в принципе на практике этого тоже достаточно.
 
На уровне БД мы оперируем записями об операциях - это основная таблица и, собственно основа учета. Мы меняем реквизиты и атрибуты именно для операций
Счета - по сути - один из атрибутов операции (атрибуты и реквизиты - см. посты выше)- основной группирующий признак и естественное представление суммирующих данных об операциях
 
Детали операции - описательные данные и носят вспомогательное  значение их жесткая структура только помешает работе...
 
Если говорить о программе для магазина, то безусловно сумма по чеку (операция) должна равняться сумме стоимости товаров по чеку (кстати здесь тоже могут быть отклонения... связаные с рассчетом НДС, скидками и округлениями)
 
НО для магазина основой учета является именно товар, для нас же - платеж (операция). Поэтому пример с магазином и кассовым аппаратом не совсем адекватен там другие цели и задачи.
Сдается мне, что рассчет в запросе суммы операции на основе суммы записей по операции просто не нужен. Это излишнее усложнение. Пусть будет автосуммирование по операции на событие AfterUpdate записи о расходе, но возможность редактировать сумму по операции ручками должна остаться в люб. случ.