吃饭，是一个人在日常生活中必不可少的部分。吃饭的属性，又会根据场景的不同而变化。
如何能将不同种类的「吃饭」，在记账软件中准确的记录呢？这里的准确不仅仅是指金额准确，更包含这一次吃的饭，它是属于生活必须品的吃饭，还是偏向娱乐化的饭局。
毕竟，记准一次吃饭的金额是很容易的。但是它的属性记录准确，才会给未来支出统计、分项预算等提供准确的供料。有了准确的统计和具有参考意义的预算系统，记账这件麻烦事才变得更加有意义，也就更容易坚持下来。
日常的吃饭，就是常见意义的「吃饭」。支出分类通常是，吃饭。
这是最为常见的一种形式，也有着最没有争议的记录方式。
值得一提的是，我将线上超市购物的款项（X马，大X发等），也同吃饭（叫外卖，下馆子等）一样合并到了这个相同的类别里。过去去线下超市的购物，种类繁多，除了食材以外，还会有一些生活日用品。但是现在的线上超市购物，通常以食材为主（或者说，就是我），而平时平时线下超市会买的杯子筷子盘子碗等，通常会采用其他渠道进行购买。这样我就可以自然的把网超的消费行为，与自己的吃饭开支画上一个近似的等号了。
聚餐的吃饭，通常带有一点社交属性。
在预算层面，我把个人的吃饭（生活必须品）和社交的吃饭（生活调剂品）分别做预算。毕竟，和朋友出去吃什么，通常不是自己说了算的。如果因为和大家一起吃了顿好的（贵的），就要压缩个人作为生活必须的吃饭预算，可能有点委屈自己，也没有特别的必要。
个人吃饭，属于生活必须这一类里，它通常与叫外卖、超市买食材等等联系在一起。生活必须的吃饭预算控制，一定程度上在限制自己下馆子过多，叫贵的外卖过多等属于个人选择又是生活必须的情况。
而社交吃饭，我把它归为娱乐这一预算类别。它通常和与朋友玩桌游、看电影、看展览等等有着相似的属性。
两种预算（生活与娱乐），控制两个类型的吃饭。因为生活吃饭具有比较规律的属性，所以我通常以月为周期来进行预算控制；而娱乐属性的各项活动，活动频率很难平均到月当中，因此我采用半年度为预算周期。这样不会经常出现这个月猛超预算，下个月又有过多的预算剩余。这种预算与实际经常脱钩的情况，会让预算渐渐失去参照的作用。
吃饭 AA，在现实场景下很容易理解。但是在记账软件里想要记得清楚准确，可能需要花点小心思。
假设一种最麻烦的情况：与好友吃饭共 5 人，消费 500 元，自己用信用卡支付了 500 元，好友纷纷微信转账给自己。
我的做法是这样的：
在信用卡账户记录一笔 100 元的吃饭消费，类别是「社交饭局」。
记录一笔转账，从信用卡账户，到应收账户，400 元。
等到朋友们陆续把钱转给自己完毕后，记录一笔转账，从应收账户，到收款账户，400 元。
若在步骤一记录了，信用卡消费 500 元，后续记录一笔收入（？）400 元朋友还款，这样信用卡实际消费与记账软件的账目是对的上的。这是最直观的记录方式，但是却会虚增个人的这项支出。这样记录，会影响与它有关的预算控制（凭空消失了 400 元的单项预算），也会影响最后的生成报表（本月的支出与收入都虚增了 400 元）。
因此，将这项支出记录为 100 元，才是合理的。但是这样的话，实际信用卡账单与记账软件的净值无法对平。那么这 400 元就需要有个合理的去处，便是有着中转账户属性的应收账户。
通过记账软件中的「转账」操作，可以将实际生活中的代付、转账等操作合理的融入记账软件中，同时又不会影响实际发生在自己身上的支出与收入。如此一来，就可以达到，软件账户余额与实际账户余额可以对得上，同时软件中的支出金额也与实际情况相符合。
凡事与「报销」挂钩的行为， 一定要记「转账」，千万不要用支出或收入来描述他们。
与吃饭相类似的，差旅费也是同样的道理。虽然它们是真金白银的从自己的卡里付出去了。但是它们仅仅是你代公司付出去的。可以理解为，你从自己的卡里借给公司钱，让自己吃饭、坐火车、住酒店。等到合适的时候，公司会把这笔钱还给你的。
用「转账」来记录这些交易行为，可以让这些非实际支出，不要混入个人的真正支出的统计当中。通常情况下，每发生一笔可报销的行为，都可以记录一笔转账，从消费账户到应收账户。等到报销好了之后，再记一笔转账，从应收账户到收款账户。
如此这般，这些日常生活中发生了的交易行为，在记账软件里面是会留下印迹的，并且个人的实际账户余额，和软件中的虚拟账户余额，也是实时对应的。
看到这里，可能有人会想，吃个饭记账而已，有必要这么麻烦吗？
如果你不常回顾自己的支出统计，或者不依靠预算来规划自己的消费，想必这样的区分是没有太大意义的。只要记录一下，然后账目可以对得上，就结束了。
以前的我也是懒得不做区分，直到有一天我回顾自己的账单：
那么我二月和三月跟一月份相比，究竟吃饭是更节省了，还是更大手大脚了呢？我无法得到答案。
因为我没有准确的记录吃饭的具体属性，所以我无法准确的回顾我的消费行为。于是我才开始想办法让我的账目在回顾的时候更加清楚，于是就有了这篇文章。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。