経費精算伝票が証憑を自動生成：業務伝票から会計証憑へのつなぎ方

システムを購入すれば自動的に証憑が生成されるわけではありません。三つの前提条件が一つも欠かせません：会計科目表は最下級まで規範化し、費用類型と科目の対応関係を行ごとに確認済み、補助核算ディメンションは証憑フィールドから透過的に伝達可能。この三つのことが終わっていなければ、どのシステムも直接記帳できる証憑を生成できない。

なぜこのことは聞こえるほど簡単ではないのか

経費精算伝票は業務言語であり、誰が何のためにいくら使ったかを記録する；証憑は会計言語であり、貸借科目、金額、補助核算次元を表現する。両者の間には一層の翻訳メカニズムが必要。

翻訳の難点は1対多：同じ「旅費交通費」でも、研究開発部門の出張は研究開発支出に、営業部門の出張は販売費に、その他部門は管理費に計上；同じ1枚の証憑でも、専用インボイスを取得すれば仕入税額を分離し、普通インボイスを取得すれば分離しない；同じ1件の支出でも、従業員が立て替えればその他の未払金に貸記し、会社が直接支払えば銀行預金に貸記する。

証憑生成の八つのステップ

第六ステップの検証は必ず前倒しで行う

このステップの検証総勘定元帳システムのエラーに依存してはならない。検証に失敗した場合は下書き状態で停止し、財務担当者が理解できるエラーメッセージを表示すべきである。例えば「科目660201はプロジェクトの記入を要求しているが、伝票に提供されていない」などで、担当者が自らルールを調整して再生成できるようにする。

総勘定元帳へのプッシュ後に拒否された場合、財務が見るのは総勘定元帳システムが投げた技術エラーコードであり、どの伝票に問題があるのかも、何を修正すべきかもわかりません。

3つの前提条件とは具体的に何か

一、勘定科目表を最下位レベルまで規範化

最下層科目のみ記帳を許可する。科目マスタには is_leaf を明示し、各科目が必ず持つべき補助核算ディメンションを定める必要がある。このデータは通常、総勘定元帳システムからエクスポートし、1件ずつ有効状態を確認する。

二、費用タイプと科目の関係を行ごとに確認

これはプロジェクト全体で最も核心的な成果物であり、最も地雷を埋めやすい箇所でもある。財務は口頭で「旅費は管理費」と簡略化しがちだが、稼働後に営業部が販売費に計上すべきことに気づく。

したがってこの対応表は必ず行ごとに記入し、行ごとに確認し、財務責任者が署名しなければならない。表の構造はおおよそ次のとおり：

部門条件を空欄にするとすべての部門に適用されます；部門例外がある場合は分行して記入し、システムは条件がより精確なルールを優先的にマッチングします。

三、補助核算ディメンションを透過的に伝達可能

証憑行は部門、コストセンター、プロジェクト、従業員、仕入先などの维度を携帯する必要があります。これらはマッピング不要ですが、保証する必要があります：経費精算書にこれらのフィールドがあり、かつコードが総勘定元帳システムと一致すること。コードが一致しない場合、追加の変換対照表が必要です、この点は調査段階で明確に確認する必要があります。

検証方法：過去の書類で1件ずつ照合

ルール設定完了後、最も有効な検証手段は財務に10～20枚の実際の経費精算書とそれに対応する手作業仕訳を求め、1件ずつ試算・照合することである。これはいかなる形式の要件ヒアリングよりも、見落とされた例外ルールを露呈させやすい。

サンプルは特殊な状況をできるだけ網羅すべき：前払い消込、複数明細の合併、控除不可の仕入、期間跨ぎ、無効化・赤字訂正。これらはまさに最も問題が発生しやすい種類である。