税金や決済データを変更せずに請求書PDFを翻訳する方法

請求書PDFを翻訳する際は、内容を変更する前に、閲覧者向けの言語テキストと取引データを切り離してください。品目明細、指示事項、一部のラベルなどは翻訳が必要になる場合があります。一方で、請求書番号、納税者識別番号、日付、数量、通貨、レート、金額、決済情報、参照番号などは、通常、元の取引データと完全に一致させておく必要があります。

以下の手順に従って進めてください：

1. 原本となる発行済み請求書は、正本（記録の原本）として一切変更しない。
2. 翻訳版の用途が、社内での参照用コピーか、公式に提出・承認される翻訳物かを判断する。
3. すべてのフィールドをリストアップし、翻訳対象、変更禁止（固定）、発行元管理のいずれかに分類する。
4. 保護された取引データ層には手を触れず、説明文やテキスト部分のみを翻訳する。
5. 識別番号や数値フィールドを機械的に照合する。
6. 各明細行、小計、税額、合計額を再計算して確認する。
7. エディタのプレビュー画面だけでなく、実際に書き出されたPDFファイルを検証する。

本記事の サンプル請求書 と 原文・訳文監査ワークシートをダウンロードするか、 テストデータの解説をご覧ください。このサンプルには架空の企業名、識別番号、2件の明細行、整合性の取れたEUR合計額が使われており、実際の財務ドキュメントをアップロードすることなく検証手順を試すことができます。

まず翻訳版請求書の用途を明確にする

社内参照用の控えと、税務当局、裁判所、銀行、監査人、顧客、経費精算システムによって受理される請求書とでは、成果物に求められる基準が異なります。

社内参照用の場合、主な目的は財務部門や運用チームが品目、サービス内容、支払指示、取引の背景を理解できるようにすることです。法的な効力を持つ正本はあくまで原本の請求書であり、翻訳版は付属資料としてラベル付けして保管する必要があります。

公的機関等への正式な提出を目的とする場合、要件を決めるのは提出先です。公認翻訳（法定翻訳）、翻訳証明書、表示されている全フィールドの完全な翻訳、特定のファイル形式、あるいは原本と訳文の併記提出などが求められる場合があります。一般的な翻訳ワークフローから推測で判断せず、提出先の規定を必ず確認してください。

この違いが極めて重要なのは、請求書が一般的な文章ではなく、構造化された取引証明書類だからです。欧州委員会（European Commission）の最新の VATインボイスに関するガイダンス には、一意の連番、サプライヤーと顧客の詳細、品目名と数量、単価、取引日、付加価値税率、付加価値税額、リバースチャージなどのケースに応じた特定の文言といった項目が挙げられています。英国のガイドラインでも同様に、 一意の請求書番号、日付、品目内容、金額、付加価値税、請求合計額が記載されています。詳細な規則は取引内容や法域によって異なりますが、「データを正確に保持する」という原則は変わりません。

翻訳前に項目の棚卸しを行う

各項目を文の断片としてではなく、属性を持つオブジェクトとして扱います。行項目のデータが別の行へ勝手に移動してしまわないよう、繰り返される明細フィールドには固定のIDを割り当てます。

数字だけを保護すればよいわけではありません。マイナス記号、通貨コード、小数点記号、パーセント記号、税ラベル、列の見出しなども、その数値の意味を左右します。

翻訳、ローカライズ、換算を明確に区別する

これらはそれぞれ異なる処理です。

• 翻訳は Calibration certificate copy 言語を変更する処理です。
• 例えば、 2026-09-15 を次のように表示すること： 15 September 2026 は日付を保持したまま表記を変更する行為です。
• EURからUSDへの換算は財務データを改変する行為です。そして、
• サプライヤーの登記名を翻訳言語のマーケティング名に置き換えることは、法人識別情報を改変する行為にあたります。

承認されたローカライズ内容はすべて個別に記録してください。翻訳先の読者にとって馴染みがあるというだけの理由で、通貨換算、税額の再計算、単位変換、または法人名の置き換えを決して行ってはなりません。

発行済みインボイスを保持し、複製したファイルで作業する

原本ファイルは読み取り専用のまま保持してください。翻訳後の派生ファイルには、新規に発行された請求書と誰も誤認しないような名前を付けます。社内用の表記としては、業務プロセスに沿うものであれば Translation for reference — source invoice remains authoritativeなどが有効です。

アップロードや外部への引き渡しを行う前に、以下の点を確認してください。

• 利用規約、継続ページ、クレジットノート（返金伝票）の参照情報などを含め、いかなるページも削除しないこと
• 添付ファイル、コメント、フォームフィールド、署名、非表示レイヤーの有無を特定すること
• PDFに選択可能なテキストが含まれているか、それともページ全体が画像であるかを確認すること
• 文書を処理できる権限者と、承認済み環境の外部への持ち出しが許可されているデータを確認すること
• 翻訳に使用した正確なソースファイルの不変なコピーまたはハッシュ値を保存しておくこと

インボイスには、氏名、住所、納税者番号、銀行口座情報、機密性の高い品目情報などが含まれる場合があります。外部サービスを利用する前に、 文書翻訳におけるプライバシーチェックリスト を適用してください。銀行口座の上に黒い四角形を重ねて隠すだけでは、その下にある元データが実際に削除され、検証されていない限り、プライバシー対策とは言えません。

納品内容を変更せずに品目明細を翻訳する

各行の品目明細は一見シンプルに見えても、製品バリアント、サービス期間、モデル番号、契約範囲などの情報が暗号のように組み込まれていることがよくあります。明細は、保護すべきトークンと翻訳可能な通常テキストに分割して処理してください。

例：

定期的に発生する品目、サービス、税金、商取引条件には用語集（グロッサリー）を使用してください。用語集は言語表現を統一するためのものであり、根本的な会計データを書き換えてはなりません。原文の用語が曖昧な場合は、最も自然に見える訳を勝手に選ぶのではなく、作業を止めて請求書の発行元に確認してください。

法的に定められた定型フレーズには細心の注意が必要です。EUのガイドラインでは、次のようなケースで使用される文言が規定されています。 reverse charge, self-billing, cash accounting、マージン制度（マージンスキーム）などです。このような文言は、関連する発行元や管轄地域で承認された公式用語に厳格に従って翻訳してください。原文にない税務上のステータスを追加したり、重複に見えるからといって削除したりしないでください。

すべての明細行と合計金額を照合する

原文と訳文を並べて目視確認することは不可欠ですが、それだけでは不十分です。一見もっともらしく見える誤りを検知するために、計算の検証とフィールドごとの比較を行ってください。

各明細行について、以下を検証します。

quantity × unit price − approved discount = line net

次に、原文で用いられている以下のような請求書全体の整合性を検証します。

sum(line net amounts) = net subtotal
taxable base × stated tax rate = tax amount
net subtotal + tax + approved charges − approved credits = total due

実際の請求書の税計算や端数処理ルールが異なる場合に、これらの計算式を無理に適用しないでください。そうではなく、原文で明示されている計算方式と端数処理ルールを正確に再現した上で、原文と訳文の結果を比較してください。

ダウンロード可能な検証用ワークシートは、限定的なケースの一例を示しています。

また、保護すべきすべての文字列（請求書番号、VAT番号、発注番号（PO）、IBAN、BIC、通貨コード、支払いリファレンス）も突き合わせてください。数値の差分チェックだけでは、顧客の納税者番号の入れ替わりや、銀行参照番号の途切れなどを検知できません。

PDFの構造とOCRに慎重に対処する

個々の単語が選択できるか、コピーしたテキストが表示上の読み順に従っているかをテストしてください。請求書は実際の表組みではなく位置指定されたテキスト断片で構成されている場合があり、見た目が正しくても抽出時に品目説明と金額が混ざってしまうことがあります。

テキストベースのPDFの場合は、レイアウトを認識できるワークフローを採用し、最もレイアウトが複雑なページからテストしてください。以下の点を確認します。

• 説明文が長い明細行
• 次ページ以降の繰り返しヘッダー
• 割引、クレジット、およびマイナス金額
• 複数の税率や通貨
• 支払い指示の横に記載された合計金額
• フッターの取引条件、銀行口座情報、および法的文言

画像のみの請求書の場合、OCRは原文データを復元するための独立した工程となります。翻訳を行う前に、すべての識別番号や数値をページ画像と照合してください。 0/O, 1/Iなどのよくある誤認識や、小数点・マイナス記号の脱落、列の結合などは、翻訳モデルに渡る前の段階で取引内容を変えてしまう恐れがあります。 スキャンPDF向けワークフロー を利用し、比較照合用の基準として元のページ画像を手元に残しておいてください。

BookTranslatorは、対応するPDFファイル全体の翻訳に対応しています。テキスト選択が可能なファイルでレイアウトを維持することが重要な場合は、標準のPDF翻訳が適した選択肢です。OCRモードはスキャンデータや画像主体のページからコンテンツを読み取り、読みやすい翻訳済みPDFとして再構築できますが、元のページレイアウト、フォント、フォントサイズの完全な再現を保証するものではありません。また、BookTranslatorは請求書の発行、税務処理の検証、翻訳証明の発行、支払い指示の承認を行うものではありません。

これらの制約が要件に合う場合は、代表的なサンプルファイルを PDF翻訳ツールでテストしてください。支払い前にタスクの詳細を確認し、ダウンロードした文書は元の構造がそのまま維持されていると思い込まず、新たな成果物として見直すようにしてください。

出力されたPDFを取引文書として確認する

完成したファイルをビューアで新たに開き、3段階のチェックを実施します。

1. フィールドの確認

• 保護すべきすべての識別番号を1文字ずつ照合します。
• すべての日付をその意味と役割（発行日・支払期日など）に沿って照合します。
• 数量、単価、割引、税率、税額、合計金額の各フィールドを照合します。
• 品目の説明文が正しい行に紐づいているか確認します。
• 原文と翻訳文で請求明細行の数が一致しているか確認します。

2. 計算の確認

• 各行の金額を再計算します。
• 該当する場合は、税区分ごとの小計を検算します。
• 原文と同じ計算方式と端数処理を使って税額を再計算します。
• 控除額、デポジット、支払済金額、未払残高の整合性を確認します。
• わずかな差額であっても翻訳時のノイズとして片付けず、すべての差異を徹底的に調査します。

3. PDFパス

• テキストの溢れ、見切れ、列のズレ、改ページ位置を点検します。
• 明細テーブルをプレーンテキストとしてコピーし、読み上げ順・読書順を確認します。
• 請求書番号や発注書（PO）番号の参照をすべて検索・照合します。
• リンク、添付ファイル、コメント、フォームフィールド、署名が存在する場合はそれらを検証します。
• 翻訳版であることを示すラベルが、必須の請求書項目を覆い隠していないか確認します。

フォント、言語カバレッジ、画像、アクセシビリティ、最終ファイルのチェックには、より包括的な PDF翻訳QAチェックリスト を活用してください。情報が密集した表については、 PDFの表とグラフの処理ワークフロー.

新規の請求書と誤認されるおそれがある場合の公開停止基準

以下のいずれかに該当する場合は、翻訳ファイルをリリースしないでください。

• 受領側の認証要件や完全性に関する規則が不明な場合
• 原本と翻訳版の区別がつかない場合
• 請求書、税務、発注書、または支払に関する識別子のいずれかが異なっている場合
• 品目明細の説明文を元の該当行へ確実に紐付けられない場合
• 原文と訳文の計算結果が一致しない場合
• OCRの読み取り精度の問題が、数字、符号、小数点、または識別子に影響を与えている場合
• 署名や構造化電子インボイス層が責任者の承認なく改変されている場合
• 完成したPDFを再度開き、第三者による独立した確認を行っていない場合

実務上のルールは極めて厳格です。言語のみを翻訳し、取引の事実はそのまま維持し、フィールド比較と計算検証によってその完全性を証明しなければなりません。どれほど自然な日本語訳であっても、誰が何を納品したのか、請求額はいくらか、税額がどう記載されていたのか、あるいは支払先がどこなのかが変わってしまえば、その翻訳は失敗と言わざるを得ません。