第６回　採番について

◆タイの複雑なドキュメントNo.（採番）

請求書（Invoice）などの書類に固有の番号を付けることを「採番」と呼びます。

この採番についても、日本とタイでは運用方法が大きく異なります。

日本では、会計システムを導入した時点から、Invoiceなどのドキュメントに順番に番号を振っていく方法が一般的です。

発行したInvoiceに誤りがあった場合には、そのInvoiceを取り消したうえで、修正版を新しい番号で発行するなど、重複を防ぐ仕組みを取ります。

一方、タイでは、月次での会計処理と税務申告を前提としているため、InvoiceやReceiptなどのドキュメントNo.についても、月単位で管理する必要があります。

さらに、原則として発生日の順番に番号を割り当てることが求められるため、特別な理由のない欠番は問題となります。

例えば、次のような番号体系です。

IV201605-001

「IV」はInvoiceを表し、その後に年月、連番が続きます。

企業によっては、IVの前に企業名などを表す記号を付ける場合もあります。

このように、単に「重複しない番号を付ければよい」という日本の採番とは異なり、タイでは月、発生日、連番という複数の条件を考慮して採番する必要があります。

◆ドキュメントNo.を修正するときの難しさ

タイの採番で特に難しいのが、Invoiceなどの書類に誤りがあった場合です。

月ごとの連番が採番ルールとして定着しているため、単純に「間違ったInvoiceを削除して、新しい番号で発行し直す」という方法を取ることが難しい場合があります。

例えば、Invoiceを発行した後、取引先から、

「単価を下げてほしい。Invoiceは同じ番号で再発行してください」

と言われたとします。

納品側がこれに応じてInvoiceを作り直すと、同じInvoice No.なのに、内容の異なるInvoiceが複数存在するという事態が発生します。

ここには、会計システム上の大きな問題があります。

どちらが正式なInvoiceなのか。

最初に発行されたInvoiceはどう処理されたのか。

修正されたInvoiceは誰の承認を受けたのか。

こうした履歴を明確に残しておかなければ、後から取引の実態を確認することが難しくなります。

◆採番は単なる番号管理ではない

この問題を単純に「Invoice No.の付け方の違い」と考えてはいけません。

採番は、取引そのものの証跡を残す仕組みでもあるからです。

特にタイでは、税務申告と日々のドキュメントが密接に結びついています。

そのため、Invoiceを発行した後に内容を変更する場合でも、

• 元のInvoiceを残す
• 取消処理を記録する
• 修正理由を明確にする
• 修正版との関係を記録する
• 番号の連続性を維持する

といった管理が重要になります。

もし、この履歴が残らなければ、意図的な取引隠しや売上操作などを疑われる余地が生まれてしまいます。

◆不正を防ぐための仕組み

採番の問題は、単に会計担当者が注意すれば防げるものではありません。

日々の取引件数が多くなればなるほど、人手による管理には限界があります。

例えば、

• Invoiceの発行
• Invoiceの取消
• Credit Noteの発行
• Invoiceの修正
• 入金処理
• 在庫の引落し

などを、それぞれ別々に管理していたのでは、取引全体の整合性を維持することが難しくなります。

そこで重要になるのが、ドキュメントNo.と取引情報をシステム上で一体管理することです。

さらに、毎月末に行われる在庫管理との照合も重要です。

Invoice上の販売数量と実際の出荷数量、そして在庫の減少量が一致しているかを確認することで、異常な取引を発見できる可能性があります。

◆タイの会計システムに求められる採番管理

日本の会計システムでは、採番は比較的単純な機能として扱われることがあります。

しかし、タイでは、採番そのものが税務・在庫・売上・証憑管理をつなぐ重要な機能になります。

したがって、タイ向けの会計システムでは、

「番号を自動的に振る」

だけでは不十分です。

「なぜその番号になったのか」
「そのInvoiceは最終的にどう処理されたのか」
「修正前と修正後の関係はどうなっているのか」

まで追跡できる仕組みが必要になります。

特に取引件数の多い企業では、こうした管理を人手だけで行うことには大きなリスクがあります。

タイで事業を行うのであれば、採番を単なる事務作業として考えるのではなく、税務上の証跡と企業内部の不正防止を支える重要な内部統制の一つとして考える必要があるのです。

「転ばぬ先の杖」という言葉があります。

採番についても、問題が発生してから対応するのではなく、最初から不正やミスが起こりにくい仕組みをシステムとして構築しておくことが重要なのです。