トルコの電子インボイス連携: e-FaturaとERPソフトウェア開発

トルコで事業を営むなら、ERPは通常、歳入庁(GİB)の制度のもとでe-Faturaとe-Arşivに対応し、業種によってはe-İrsaliyeにも対応します。文書はUBL-TR形式で作られ、売り手は財務印(mali mühür)で署名し、私設インテグレーターがGİBと照合し、保管の責任は納税者の側に残ります。

トルコで事業を営むためにERPが備えるべきもの

トルコの電子インボイスは、クリアランス方式で運営されています。売り手が文書を作り、認可されたチャネルで送信し、歳入庁が検証し、それから初めて法的な効力を生じます。ERPで事業を回している企業にとって、これはシステムの4か所に影響します。

文書の生成。 ERP(または接続されたエンジン)は、スキーマが求めるコード、当事者の識別子、明細レベルのデータを伴う、要求されたUBL-TR構造で請求書を生成しなければなりません。印刷レイアウトをXMLに押し変えたものでは足りません。

電子署名。 文書には納税者に発行された財務印で署名します。署名のステップはフローの内側にあり、鍵の扱いは印の保管体制に合わせたものでなければなりません。

双方向の交換。 e-Fatura制度では、相手方の登録ステータスが文書の型を決めます。受信文書――受け取った請求書、応答、許される場合の取消――は元の識別子を伴ってERPに戻らなければならず、そうでなければ会計はシステムと公式記録のつながりを失います。

アーカイブと検索。 発行・受信した文書は法定の保管期間中、取り出せる必要があります。インテグレーターが保管するのか、ERPが保管するのか、あるいは両方なのかは、監査の要求が来るあとでなく、公開前に下す決定です。

多くの企業がERPを組み直すのではなく接続してこれを満たします。ERPと私設インテグレーターの間の連携レイヤーを作り、顧客・品目・価格・会計のシステム・オブ・レコードはERPのままにします。

クリアランス方式に慣れないチームが驚く構造上のポイントが1つ。請求書は、ERPで印刷された時点で終わるのではありません。交換が完了し、応答が返ってきた時点で完了します。つまり、請求書の状態というERPの考え方が、「作成」「送信」を超え、承認・却下・修正まで含めなければならないのです。これを怠った企業は、月末に自らの元帳と公式記録という2つの真実を突き合わせることになり、電子インボイスが取り除くはずだった仕事そのものが残ります。

もう1点はタイミングです。クリアランス方式の文書は、メール添付のような非同期ではありません。却下はチームがまだ働いている間に届き、それが求める修正は、たいてい文書自体でなくマスターデータに触れます。原因を直せる人がその場で通知され、月次レポートで発見するのではなくなるようにフローを設計することが、「動いているだけのシステム」と「見張りが必要なシステム」の分かれ目です。

e-Fatura、e-Arşiv、e-İrsaliyeの整理

文書	用途	典型的な発生契機	注記
e-Fatura	e-Faturaに登録済みの納税者間のB2Bおよび官公庁向け請求書	双方がe-Faturaに登録済み	登録済み当事者間で交換される構造化文書。相手方のステータスが経路を決める
e-Arşiv	e-Faturaに登録されていない買い手向けの請求書――小売・B2C、および一部のB2B	売り手が対象内、買い手はe-Fatura制度の対象外	買い手にはPDFとして整形されるが、生成と申告は同じチェーンを通る
e-İrsaliye	ルールが指定する業種・取引のための電子納品書	対象フロー内の貨物の出荷	請求書と連結する:納品書と請求書が相互参照する
e-Defter	帳簿・記録――総勘定元帳と日記帳――の電子申告	適用ルールに基づく対象の納税者	電子インボイスとは別の義務だが、同じプロジェクトで計画されることが多い

どの義務が誰に及ぶかは、変わり続けるGİBの規則と通達で定義され、閾値と業種の指定は当局が決め、当局とともに変わります。買い手にとって正しい記述は手続上のものです。連携を設計する前に、自分の会計士または税理士を通じて現行ルールに対して登録ステータスを確認してください。記事によって――この記事を含めて――ではなく。

連携の選択肢

選択肢	適合	ERP側の作業量	注意点
GİBポータル	極少量、手動発行	ERP側の作業なし	手動で遅く、ERPを持つ事業の設計目標ではない。予備としてだけ保持する
私設インテグレーター(özel entegratör)	大半の事業の定番の経路	インテグレーターのAPIまたは形式への接続＋マッピング	ロゴでなくサポートとAPI品質で比べる価値がある。スキーマ更新を誰が保守するかを聞く
GİBへの直接接続	制御をすべて握りたい規模の大きい事業	高い:チャネルの技術・運用責任を自ら負う	取得も運用もより複雑で、実務上まれとされる。例外として正当化するもので、既定ではない

インテグレーターのモデルは誤解されがちなので、1つ明確にしておきます。私設インテグレーターを使うことは、納税者の義務を移譲しません。インテグレーターが提供するのは技術のチャネル、送信、保管のサービスです。文書の法的責任――その正確さ、発行、そして税収手続法(Tax Procedure Law)に基づく保管――は納税者の側に残ります。インテグレーターの販売ページが、コンプライアンス問題を代わりに解いてくれるような文調だったら、その一節をもう一度読んでください。

実務ではこの分担が、小さく具体的な形で現れます。顧客の税識別子が自社マスターで間違っていて文書が却下されたなら、インテグレーターのシステムは完璧に動き、直すべき誤りはあなたのものです。誤った税コードで請求書を発行したなら、どのチャネルチェックも救ってくれません。インテグレーターはインフラであり、流れてくるデータの質は社内の規律であり、その規律が組み込まれるのか習慣に任せるのかを決めるのはERPです。したがって、インテグレーターを比較する買い手は機能一覧に費やす時間を減らし、何かが壊れたときに誰が何をするかを明らかにする問いに時間をかけるべきです。誰が誰に、どの形式で警告し、修正済み文書をどれだけ速く再送できるのか。

実装手順とテスト

ERP側連携として成立する順序は次のとおりです。

義務のスコープを確定する。 会社の会計士とともに現行ルールに照らし、どの文書が自社に当てはまるか――e-Fatura、e-Arşiv、e-İrsaliye、e-Defter――を確認します。

チャネルを選ぶ。 多くの企業は私設インテグレーターを選びます。選定の問い――APIの品質、サンドボックスの有無、サポートの言語と時間帯、スキーマ更新の扱い、リファレンス――はそれ自体で短名簿作業に値します。

マスターデータをマッピングする。 顧客とその税識別子、品目、単位、通貨、税コードを、スキーマの期待に合わせる必要があります。ここでの不一致が、のちの誤りの最大の単一要因です。

文書フローを設計する。 誰が何を作り、いつ印を押し、失敗時はどうなるか、送受信した文書をERPの記録とどう突合し、修正をどう発行するか。

テスト環境を使う。 両者がテスト環境を提供しています。公開前に、すべての文書型、すべてのエラー経路、すべての修正シナリオを、本番と同じマッピングで通してください。

エラーをプロセスとして扱う。 却下は送信後に届きます。誰かがそれを見て、原因を理解し、基礎データを直さなければなりません。責任者なしの警告受信箱が、企業を文書の遅延発行に追い込みます。

アーカイブとアクセスを計画する。 文書をどこに保管し、誰が取り出せるか、監査の要求に保管期間内でどう答えるか。

成否を分けるのはインターフェースではなく、手順3、6、7、すなわちデータの質、エラーの責任、取り出しです。プロジェクトチームが帰ったあともこれらは続くからです。

外資系・非居住者として税理士に持っていく論点

外国に親会社がある企業、あるいは地域の財務チームを整えずにトルコへ入る企業にとって、いくつかの問いはITプロジェクトでなく税理士に属します。答えが設計を決めるため、連携のあとでなく前に尋ねてください。

登録の経路。 会社はどうやって義務の対象となるのか、申請に署名するのは誰か、どの代理人が認められるのか。税務登録の問いであって、ソフトウェアの問いではありません。

印の取り決め。 財務印を会社はどう取得するのか、署名者がトルコ国外にいるとき、保管はどう組織するのか。

代理人と署名。 誰がどの文書に署名する権限を持ち、監査証跡のためにERPは署名者について何を記録しなければならないのか。

海外子会社の立場。 非居住者的所有の会社に追加要求が及ぶのか、グループ内の請求はどう扱われるのか。

これらを意図的に「問い」として述べるのは、登録や代理人のルールが変わり、現地固有であり、製品ページがそれを資格づけられないからです。ITプロジェクトができるのは、答えが遅いことを前提に設計すること――文書フローを特定の仮定にハードコードせず、設定可能に保つことです。

税理士との関係の持ち主を決めたほうがよいのも同様です。財務とITがお互いが聞いたと想定しあっている会社では、これらの論点は連携に遅れて届き、たいてい公開前の数週間、文書フローがすでに固まったときに現れます。双方に名指しの責任者を置き、実装の手順3の前に一度共同の会議を開けば、その大半を防げます。

よくある問題

この種のプロジェクトで最も頻繁に現れる失敗と、それぞれが通常指すもの。

検証での却下。 ほぼ常にマッピングの問題です。税コード、識別子の形式、スキーマの期待と合致しない明細レベルの項目。リトライロジックでなく、マスターデータを直してください。

番号の重複。 複数のシステムが生成した、または障害後に再生成された連番。連番はちょうど1つの責任者と、文書化された復旧ルールを持たなければなりません。

相手方ステータスの誤り。 顧客の登録ステータスをキャッシュしたまま、または推測して、誤った文書型を発行する。ステータスは記憶でなく、インテグレーターのルールに従って照会してください。

受信文書の紛失。 受信したがERPへ計上されなかった文書。その結果、買掛金業務が別画面で回ります。交換の方向は付加的な選択肢ではなく連携の一部です。

スキーマ更新の見落とし。 構造は時間とともに変わります。責任者は、いつ変わり、マッピングに何を及ぼしたかを知っていなければなりません。

締め切りでのテスト省略。 上記のいずれもテスト環境のほうが安く済みます。公開の圧力が、それらをインシデントに変える場所です。

よくある質問

e-Faturaとe-Arşivの違いは何ですか

e-Faturaは、制度に登録済みの納税者間で交換される請求書――登録済み当事者間の構造化文書――を対象とします。e-Arşivは、買い手がその制度の対象外の請求書――小売・B2B、および一部のB2B――を対象とし、買い手は通常、同じ公式チェーンで生成されたPDFを受け取ります。ある請求書にどちらが当てはまるかは相手方の登録ステータスから決まります。だから連携は推測ではなく、それを照会するのです。

私設インテグレーターは必要ですか

多くの企業には必要です。それが定番の経路であり、直接チャネルは複雑でまれとされます。私設インテグレーターはGİBへの技術チャネルと保管サービスを提供します。納税者としてのあなたの義務はあなたのままです。選定は調達の作業です。日々の体験をブランドより左右するのは、APIの品質、サンドボックス、サポート、スキーマ更新の扱いです。

財務印(mali mühür)とは何か

送信前に電子文書へ署名するために納税者が使う、電子署名の資格です。保管と、誰がそれを使えるかは、会社の中で決める実務の問いです。署名者がトルコ国外にいるチームにとって、印を誰が持ち、誰が押すかの取り決めは、税理士に最初に持っていく論点の1つです。

任意のERPでもトルコの電子インボイスは発行できますか

いいえ。ERPは、正しいマスターデータで要求されたUBL-TR構造を生成しなければならず、できないならそれを行うエンジンまたはインテグレーターに接続する必要があります。標準の請求書レイアウトでは足りません。だから多くの企業は組み直さず接続します。ベンダーに問うべきは、コネクタがどのインテグレーターに対応し、何をマッピングし、文書がどこにあるかです。

公開前にどうテストすればよいですか

インテグレーター側と公式側の両方が用意するテスト環境を通じて、本番と同じマスターデータのマッピングを使い、すべての文書型、すべての却下経路、すべての修正、ERPへ計上される受信文書を確認します。テストをエラー処理のリハーサルとしても扱ってください。誰かが却下を受け、診断し、直さなければならないのであり、緑のチェックマークを見るだけでは足りません。

請求書は誰が保管しますか

保管の責任は税収手続法(Tax Procedure Law)に基づき納税者の側に残ります。インテグレーターは通常、技術的な保管を提供し、多くの企業は日常の利用のためにERPにも文書を保持します。大切なのは、公開前に取り決めを決め、保管期間内に誰がどの文書を出せるかを知り、監査員が求める前にその取り出しをテストすることです。

出典と規格

GİB — Gelir İdaresi Başkanlığı――歳入庁は、e-Fatura、e-Arşiv、e-İrsaliye、e-Defterの規則、通達、技術文書を公表しています。そこの現行版が、このページに要約されたすべてに優先します。
登録ステータス、閾値、業種の指定、期限は当局が定め、変わります。会計士または税理士を通じて現行ルールに照らして確認してください。本ページのいずれも税務助言ではなく、WorldwideTradeXについてのインテグレーターとの関係、提携、認証の主張もありません。