2307がSAWTまたはQAPの行になるために
必要な3つの照合
BIR(Bureau of Internal Revenue)Form 2307は証明書であり、アルファリストの行ではありません。これは期間、2つの納税者ID、および一連の月次金額を記録します。SAWT(源泉徴収税の概要アルファリスト)とQAP(支払先の四半期アルファリスト)は、これらの同じ事実を異なる形で切り分けて求めます。四半期末の手戻りのほとんどは、入力作業ではなくこの切り分けで発生します。
顧客から受け取った証明書はSAWTに反映されます。仕入先に発行した証明書はQAPに反映されます。中規模の財務チームでは、両方の作業が同じ担当者に集まります。AR担当者は受け取った証明書を追跡し、AP担当者は発行済みの控えを保管し、税務会計士はファイルを作成し、申告担当者はモジュールを実行し、後から外部監査人が両者が一致しているかを確認します。本記事では、証明書が有効な行になるかを決める3つの照合を追い、その後、あなたのファイルと相手方のファイルの間で行われる4つ目の照合を扱います。

主なポイント
- 四半期を間違えると、正しい金額でもクレジットが否認されます。
- 2つの税コード行と3か月分の支払いがある1つの証明書から、6つのアルファリスト行が生成されることがあります。
- あなたの源泉徴収リストが正しくても、証拠の半分は源泉徴収義務者のファイルにあるため、失敗することがあります。
2つのアルファリスト、1つの証明書レイアウト

アルファリストとは、納税者が申告書に添付する行単位の一覧です。SAWTは、所得から税を源泉徴収した源泉徴収義務者の支払先側の一覧であり、QAPは、源泉徴収義務者が源泉徴収した支払先の一覧です。同じ取引を反対側から見たものです。BIRのアルファリストモジュールは最初のファイルをSummary Alphalist of Withholding Taxesと呼び、Revenue Regulations (RR) 2-2006はこれを源泉徴収義務者の概要と説明しています。どちらの名称も同じ添付書類を指します。
SAWT自体に申告期限はありません。クレジット可能源泉徴収税(CWT)のクレジットを申請する申告書に添付され、納税者とクレジットの内容に応じて、1701Qまたは1702Qの所得税申告書、あるいは2550QのVAT申告書となります。QAPは1601-EQ(四半期拡張源泉徴収税申告書)または最終源泉徴収税の1601-FQに添付され、四半期終了後の翌月末日が期限です。QAPは1601-EQと同じ期限を共有するため、申告書より後に提出すると遅延となります。
| ファイル | SAWT | QAP |
|---|---|---|
| 作成者 | 所得を受け取り、税を源泉徴収された支払先 | 支払い、源泉徴収した源泉徴収義務者 |
| 作成の基になるもの | 受領した2307証明書 | 発行した2307証明書 |
| 行の相手方 | 源泉徴収義務者、または支払者 | 支払先 |
| 添付先 | クレジットを記載する申告書 | 1601-EQまたは1601-FQ |
| 期限 | その申告書と同時 | 四半期後の翌月末日 |
行の単位は証明書より小さくなります。アルファリストの1行は、1つの相手方、1つのATC、1つの月です。2つのATC行と3か月すべての金額がある証明書は、6行のアルファリスト行を生成することがあります。これが最初の形の変化であり、証明書を1ページ1行でコピーして作った表が、完成したように見えてもファイルがまだ間違っている理由を説明しています。
モジュールは証明書を読み取りません。キー入力されたエントリまたは.DATファイルを受け付けます。.DATはモジュールが生成するプレーンテキストのデータファイルです。モジュールはその後、独自のテーブルと構造を照合し、レポートを返します。それ以前のすべてはデータ準備作業です。つまり、証明書の束を、正しい期間、識別情報、金額を持つ行に変換することです。
項目は証明書上にあるが、形が違う
アルファリストが求める値はすべて2307にすでに印刷されています。作業のポイントは、どの欄がどの列に対応するかを知ることです。2018年1月版の様式では、証明書は3つの部分と署名ページで構成されています。
| 記載場所 | 記載内容 | 転記先 |
|---|---|---|
| Item 1 | 対象期間、開始日と終了日 | 四半期および月の割り当て |
| Part I | 支払先のTIN、登録名称、住所 | QAP行の取引相手 |
| Part II | 源泉徴収義務者のTIN、登録名称、住所 | SAWT行の取引相手 |
| Part III、拡張ブロック | 所得支払行、ATC、第1・第2・第3月の金額、合計、源泉徴収税 | ATC、月次の所得支払、源泉徴収税 |
| Part III、事業税ブロック | 事業税の源泉徴収対象となる金銭支払、政府および民間の支払者 | 個別のATC行 |
| CONFORME | 支払先の受領確認 | 提出用コピーのみ。アルファリストの項目ではありません |
2307の納税者番号(TIN)は14桁です。9桁の基本番号に5桁の支店コードが付きます。証明書から取り出した瞬間からテキストとして扱ってください。フィールドを数値として読み込む表計算ソフトは支店コードの先頭のゼロを落とし、その行は本来なら通るはずの照合に失敗します。本社と支店は別の源泉徴収義務者であり、そのTINは最後の5桁だけが異なります。
ATCは英数字税コード(Alphanumeric Tax Code)であり、最初の2文字で源泉徴収システムのどちら側かがわかります。WIは拡張源泉徴収の個人、WCは法人、WBは事業税の源泉徴収、WVはVATの源泉徴収です。コードには適用税率も含まれます。個人に支払う専門家報酬はWI010が5%、WI011が10%、同じ報酬を法人に支払う場合はWC010が10%、WC011が15%です。どちらが適用されるかは支払先の総所得と、個人の場合はVATの課税区分によって決まり、証明書に印刷されたATCスケジュールがコードの根拠となります。
1枚の証明書に複数のATC行が記載されることがあり、拡張源泉徴収ブロックと事業税ブロックの両方が含まれることもあります。最初のブロックだけを取り込むと、事業税の源泉徴収が照合するテーブルに到達しません。コピーした合計からも欠落した行が抜けているため、四半期の合計はもっともらしく見えてしまいます。
証明書は横型です。1つのATC行に3つの月別列が横に並びます。アルファリストは縦型で、ATCごと、月ごとに1行です。この形の変換が、行が失われる最初のポイントです。
照合1:期間が四半期を決める

金額より先にItem 1を確認してください。正しい金額でも四半期が誤っていれば、そのクレジットは否認されます。証明書には所得期間が記載されており、その期間が四半期を決めます。証明書に署名した日やメール送信した日ではありません。6月分の所得に対して7月5日に発行された証明書は、第3四半期ではなく第2四半期に属します。
期間に関する失敗は3つよくあります。1つ目は、Item 1が申告する四半期の外にある証明書です。源泉徴収義務者が1月から3月分の証明書を送ってきたのに、あなたが第3四半期を準備していると、その証明書が入っていたフォルダが理由で、開いている四半期に入力されてしまいます。2つ目は、四半期より広い期間をカバーする証明書で、これは通常、源泉徴収義務者が複数の四半期を1つのフォームに統合したことを意味します。3つ目は、月別の列がItem 1の期間と矛盾する証明書で、Item 1は4月から6月と記載されているのに、最初の月の列に3月の支払いが入っているケースです。いずれの場合も、修正証明書を取得するか、正しい四半期について意図的に判断するかのどちらかです。開いている四半期に合わせて行を編集すると、クロスマッチまで問題が隠れてしまいます。
3つの月別列はひとまとまりとして確認してください。四半期の最初、2番目、3番目の月の金額はItem 1の期間内に収まっている必要があり、合計はそれらの合計額と一致しなければなりません。四半期の途中で開始または終了した取引関係では、空欄の月は正常です。期間外の月は正常ではありません。
期限は四半期にプレッシャーをかけます。QAPは四半期翌月末日に1601-EQまたは1601-FQとともに提出します。SAWTはクレジットを記載する申告書とともに提出します。1701Qは5月15日、8月15日、11月15日、1702Qは四半期後60日目、2550Qは25日目です。週末や祝日に当たる場合は期日が移動するため、古い記事からコピーした表ではなく、最新のBIRカレンダーを確認してください。
四半期ごとの締め切りはフィリピン特有のものではありません。英国のP11D filing compresses a year of benefits into a July deadline、日本のyear-end withholding statements arrive in a January batch、スペインのModelo 303 is built from a quarter of invoicesも同様です。フィリピンの場合は、同じ証明書レイアウトが2つのアルファリストに逆方向で使用される点が独特です。
四半期が終わった後に発行された証明書は正常です。Item 1が申告する四半期の外にある証明書は正常ではありません。
照合その2:TINと登録名が行を決める

アルファリストは取引先を識別情報で照合するため、TINが誤っていれば金額が正しくても行が欠落していることになり、小さなミスでは済みません。識別情報はベンダーカード単位ではなく証明書単位で決まります。ある契約では本社から、別の契約では支店から支払う顧客は、2つのTINで2通の2307を発行できます。SAWTは源泉徴収義務者の一覧なので、これは2行になります。1行に統合すると、一方の証明書の支店コードの行き場がなくなり、その1行は支払者のどちらのエントリとも照合しません。
同じ分裂はQAP側にも現れます。サプライヤーが年度の一部は支店経由で、残りは本社経由で請求することがあります。会計システムにはベンダーカードが1つ、連絡先が1つ、支払履歴が1つしかありません。証明書には2つのTINが記載されています。両方にベンダーカードのTINを入力すると、名前と金額は正しく見えても、2行のうち1行が誤りになります。
名前はもっと静かに失敗します。登録名は証明書に記載された名前であるべきで、レターヘッドの名前でも帳簿の略称でもありません。2つのアルファリストを比較する際には末尾の表記が重要です。「Inc.」の欠落や、証明書にはないカンマがあると、その行は別の取引先のように見えてしまいます。また検証ルールはñ、?、&などの特殊文字を含む名前を拒否するため、アンパサンドはアップロード前に「and」という語に変える必要があります。さらにダミーTINや「Various payees」のような一括エントリも拒否されます。これらのルールはファイル構造に関するもので支払の真実性とは関係ありませんが、ファイルが受理されるかどうかを決めます。
14桁のTIN、印刷どおりの登録名、その取引先の証明書で見たATCを保持する取引先マスタを作成します。新しい取引先は最初の証明書の時点で一度だけ確定し、その後は再利用します。毎四半期ごとに帳簿からマッピングを再構築すると、同じサプライヤーが毎四半期失敗することになります。
同じ支払者・支払先の識別情報の規律は米国の1099業務にも現れ、様式が有効になる前に2つのシステムがTINで一致する必要があります。会計事務所向けのW-2および1099フィールドマッピングガイドでは、そちら側の同等のチェックを扱っています。
金額が正しく支店コードが誤っている行は、惜しいミスではありません。相手側が照合できない行です。
照合3:ATCと金額を元帳と突き合わせる
合計が一致する四半期でも、ある月が誤った列に入っていたり、ATCが誤った税率を伴っていたりする可能性は残ります。ATCは税率そのものであるため、コードと金額は必ず一緒に確認する必要があります。WI010ではなくWC010で入力された支払は、所得金額が同一であっても、期待される税率が異なる別の行になります。
複数ATCの証明書は、行が消える場所です。専門サービスを提供し、かつ事務所を賃貸している支払先は、WI010の行とWI100の行を持つ1枚の証明書を受け取ります。その証明書が1行として入力されると、2つの税額を合計しても同じ四半期合計になるため、照合は通ってしまいます。アルファリストにはコードが1つ欠け、残った行の税率ではもはや税額を説明できません。
四半期内の税率変更は、別の種類の不一致を生みます。支払先がWI010とWI011を分ける総所得の区分を超えると、源泉徴収義務者は1月と2月は5%、3月は10%で源泉徴収することがあります。証明書には、前半の月はWI010、後半の月はWI011が表示されることもあれば、源泉徴収義務者がコードを切り替えなかった場合は、1つのコードに2つの適用税率が表示されることもあります。各月の所得に対して税額を確認してください。四半期の平均では、近いように見えても依然として誤りです。
ATCの行ごと、月ごとに、源泉徴収税額を所得支払額で割ります。その実効税率は、ATCに付随する税率と一致するはずです。WI010とコードされた行で7.5%という結果が出れば、それはシグナルです。月の内訳、所得金額、コードを確認してください。表さえあればこのチェックは機械的に行え、四半期レベルの合計が隠してしまう誤りを捉えます。
表を元帳と双方向で突き合わせます。支払先側では、顧客ごと・四半期ごとの所得支払額を売上元帳に記録された収益と比較し、源泉徴収税額をCWT売掛金と比較します。源泉徴収義務者側では、発行した証明書を仕入元帳の支払と、実際に納付した源泉徴収税と比較します。クレジットノート、前払い、四半期締め直後の支払によるタイミングの差異は実在するものです。無理に一致させるのではなく、調査してください。
差異の2つの方向は、それぞれ異なる意味を持ちます。請求しているクレジットが手持ちの証明書より大きい場合、証明書が欠落しているか未着であり、その超過分が否認の対象となる部分です。手持ちの証明書が請求したクレジットより大きい場合、税は源泉徴収されたものの取り込まれていません。2つ目はより静かで、BIRにすでに納付済みの、顧客が請求していないお金です。
月ごと、ATCごとに税率チェックを実行してください。四半期レベルの合計は、2つの相殺する誤りを喜んで純額ゼロの一致にまとめてしまいます。
4つ目の照合はファイルの外で行われる
社内の照合が通っても、BIRのクロスマッチが失敗することがあります。相手側が異なるTINや金額で申告しているためです。Revenue Memorandum Circular (RMC) 14-2025は、過大なCWTの還付または税額控除の請求におけるチェックについて説明しています。処理担当部署は、納税者のSAWTで請求されたCWTと、源泉徴収義務者の1604-Eまたは1601-Eに添付された年次または四半期のアルファリストを比較します。両者が一致すれば、2307は検証済みとして扱われます。一致しなければ、証明書だけでは問題は解決しません。
ここが支払先を驚かせる部分です。2307が本物で、正しく印刷され、正しく入力されていても、源泉徴収義務者が自身のQAPで異なるTIN、異なるATC、異なる金額を報告していれば、SAWTの行は照合に失敗します。証明書は証拠の半分であり、源泉徴収義務者のアルファリストが残りの半分です。PwCのRMC 55-2026の要約は、BIRの課税手続きにおける同じデータ照合について説明しているため、リスクは還付ケースに限定されません。
これはSAWTを編集しても修正できません。あなたの行が証明書と一致しているなら、修正は源泉徴収義務者側で行うべきものです。つまり、訂正されたQAPまたは訂正された2307です。申告前に、大口または継続的な源泉徴収義務者に対して、証明書のTIN、ATC、金額が報告予定の内容と一致することを確認するよう依頼してください。確認結果は証明書と一緒に保管します。短いメール1通で、長い調査対応の会話を避けられます。
SAWTが正しくても失敗することがあります。証拠の半分は源泉徴収義務者のファイルにあるからです。
届かなかった証明書は見えない
上記の照合はすべて、手元にあるものを比較しています。フォルダに届かなかった証明書は、どの照合にも現れません。だからこそ、証明書同士を比較するだけでなく、取引先リストを帳簿と比較する必要があります。
支払先側では、その四半期に源泉徴収の対象となる支払いがあった顧客を選び、そのうち誰が2307を発行したかを確認します。源泉徴収義務者側では、支払った仕入先を選び、そのうち誰が証明書を受け取ったかを確認します。帳簿に取引先があるのに証明書がない場合、それは源泉徴収の対象外だった支払いか、漏れのどちらかです。この区別は重要であり、取引を知る人だけが判断できます。
RR 11-2018は支払先に手段を与えています。源泉徴収義務者は四半期終了後20日以内に2307を交付しなければならず、支払先の請求があれば所得の支払いと同時に交付しなければなりません。後半が有用です。受け取る際に証明書を求める仕入先はその時点で受け取る権利があり、四半期末の慌ただしさの中で追いかける必要がなくなります。定期的に源泉徴収を行う顧客については、この請求を回収プロセスに組み込んでください。
重複ももう一つの静かな誤りです。源泉徴収義務者が2307を取消して再発行すると、古い写しがフォルダに残りがちです。RR 11-2018は、同じ2307を同じ金額、源泉徴収義務者、期間に対して二度使用できないと定めているため、訂正版を入れる際には古い証明書を外す必要があります。同じルールは、2つのファイル名で二重にスキャンされた証明書にも適用されます。ファイル名ではなく、取引先のTIN、期間、ATC、所得金額、源泉徴収税額で重複を排除してください。
2307の欠落は差異として現れません。裏付けの取れないクレジット、または請求しなかったクレジットとして現れます。
照合の前に四半期分を1つのテーブルにまとめる
照合作業はスプレッドシートで行うものです。四半期を圧迫するのは再入力です。多くの顧客を抱える事務所には、同じ2週間に証明書の束が届き、それぞれ取引先もコードも異なります。締め切りのプレッシャーがかかるのは、この入力段階です。
この転記ステップに ImageToTable.ai が役立ちます。カスタム列抽出では、必要な列名を入力すると、AIが固定位置ではなくページ上の意味に基づいて各値を特定します。支払先ごとのレイアウトに合わせてテンプレートを作る必要はありません。スキャンした証明書、eBIRForms の PDF、スマホの写真を同じバッチに入れて、同じ列に取り込めます。
| 定義する列 | 2307から取り込む内容 |
|---|---|
| Period From / Period To | Item 1 |
| Payor TIN / Payor Registered Name | SAWTならPart II、QAPならPart I |
| ATC | 各所得行のコード |
| 1st, 2nd and 3rd Month Income Payment | Part IIIの3つの月別列 |
| Total Income Payment | 印刷された四半期合計 |
| Tax Withheld | その四半期の源泉徴収税 |
計算列はテーブルの構築中に計算を行います。Month Split Check (Total Income - 1st Month - 2nd Month - 3rd Month) という列は差額を返すので、月別の合計が合わない証明書は別途確認することなく浮かび上がります。Effective Rate (Tax Withheld / Total Income) はATCと比較するための税率を示します。どちらもすでに抽出された値に対する行単位の計算であり、Excelで別途管理する数式ではありません。
もう半分はバッチ処理です。その四半期の証明書を1つのバッチでアップロードすると、1つのテーブルに統合され、証明書ごとに1行になります。bbox検証付きのレビューモードでは、セルをクリックすると、その値の元になったスキャン上の領域を確認できます。これは重ね印刷、かすれ、手書きの証明書に役立ちます。自動注釈をオンにすれば、レビュー時にボックスが用意されています。密集した手書きや複雑なレイアウトには、より高いモデルティアを使うと、そのバッチでより強力な基盤モデルが使用されます。
境界も同じくらい重要です。出力は証明書ごとに1行であり、アルファリストの「ATCごと・月ごとに1行」という形ではありません。2つのATC行がある証明書は、モジュールに入れる前に2組の行にする必要があり、デフォルトの出力では行が自動的に増えません。このツールはExcel、CSV、JSONのテーブルを生成しますが、.DATファイルの生成、eBIRForms、eFPS、eSubmissionを通じた提出、BIRの記録との検証、台帳や支払先のQAPとの照合は行いません。転記をなくし、突合はあなたに残します。
ファイルは安全に処理され、保存されません。
判断が要る部分ではなく、転記にあたる部分に抽出を使ってください。
提出前チェックを、エラーが表面化する順に
モジュールのエラーの多くは入力時点で生まれています。検証レポートはそれを指摘するだけです。期間の誤りがあると以降の合計がすべて無意味になるため、エラーが実際に表面化する順にチェックを実行してください。
| チェック | 検出できるもの | 入力前の修正 |
|---|---|---|
| 1. 束を重複排除する | フォルダに残った取消済みの2307、または二重にスキャンされた証明書 | 証明書ごとに1行を保ち、差し替えられた写しを削除する |
| 2. Item 1を読む | 別の四半期の証明書、四半期より広い期間、期間外の月 | 訂正証明書、または正しい四半期への意図的な割り当て |
| 3. TINと名称を確認する | 支店コードの欠落、先頭のゼロの消失、ダミーTIN、名前に含まれるñや& | 証明書に印字された14桁のTINと登録名称を使用する |
| 4. ATCと税率を確認する | 2行のATCが1行に統合されている、四半期内での税率変更 | ATCごと・月ごとに1行とし、適用税率を比較する |
| 5. 合計を突き合わせる | 源泉徴収税と申告したクレジット、収入と帳簿 | 差異を調査する。平均化してごまかさない |
| 6. 相手先の漏れを探す | 帳簿にあるが証明書がない源泉徴収義務者または支払先 | 提出後ではなく入力前に追跡する |
| 7. モジュールを確認する | 古いバージョン、または現在のテーブルにないATC | 最新のAlphalist Data Entry and Validation Moduleを使用する |
| 8. 提出して証拠を保管する | 検証に失敗したアップロードが未受信として扱われたもの | 5日以内に完全な訂正リストを再提出する |
テーブルが整えば、手順は短いです。モジュールに行を入力し、検証を実行し、レポートが指摘した行を修正し、.DATを生成し、eFPS、eSubmissionまたはRDOメールで提出し、受付確認を保管します。テーブルが入力であり、モジュールが形式チェックです。
モジュールのリリースは重要です。新しいATCと更新された税率がそれに伴って提供されるからです。Revenue Memorandum Circular (RMC) 15-2025は、新たに作成された英数字税コードと、クレジット可能源泉徴収税および最終源泉徴収税の更新税率を伴うバージョン7.4を発表しました。ワークステーションにインストールされたコピーを信用せず、申告前にBIRのダウンロードページを確認してください。古いモジュールは、証明書上で有効なコードを拒否することがあります。
Revenue Memorandum Circular (RMC) 5-2014は、アルファリストが受領されたと見なされるかどうかを決める条件を列挙しています。有効なTIN、ダミーTINがないこと、完全な氏名、特殊文字がないこと、一括エントリがないこと、そして現在のモジュールバージョンです。アップロードに失敗したファイルは未受領として扱われ、関連する経費が否認される可能性があります。同じ回状は、失敗通知から5日以内に修正された完全なリストを再提出することを定めています。修正されたリストは、変更された行だけでなく、完全でなければなりません。
提出チャネルは、eFPS、eSubmissionアドレス、または税務地区担当官のメールアカウントです。検証の確認応答は申告書とともに保管してください。確認応答が返ってこないメールは、アルファリストが提出された証拠にはならず、そのギャップは通常、税務調査の際に発覚します。PwC's summary of RMC 55-2026によると、提出の失敗または不完全な情報の提供に対する罰則は1件あたりP1,000で、暦年でP25,000が上限です。
検証は診断です。修復はレポートではなく、テーブル内で行われます。
抽出が止まり、判断が始まる場所
ツールは証明書の値をテーブルに配置できます。どの四半期に請求するか、どのATCが適用されるか、支払先のアルファリストが正しいかどうかは判断できません。これらは取引、相手方、時には税務地区事務所を必要とする判断です。
境界は具体的です。ImageToTable.aiは.DATファイルを生成せず、eBIRForms、eFPS、eSubmissionに提出せず、BIRの記録に対してファイルを検証しません。源泉徴収税を計算せず、ATCを選択せず、経費が損金算入可能かどうかを教えません。あなたのテーブルを元帳や相手方のQAPと照合しません。これらは抽出ステップの範囲外であり、それらを自動的と見なすことが、きれいに見えるテーブルが裏付けのないクレジットになる原因です。
判断のポイントも同様に具体的です。遅延した証明書が修正申告に属するのか後の申告に属するのか、支店のTINを別の行にすべきか、2つのATCの間に位置する支払いをどう分類するか、支払先のQAPが異なる金額を記載している場合にどうするか。これらは税務アドバイザーまたはRDOに相談してください。その線が、データ作業と税務作業の分かれ目です。
よくある質問
SAWTとQAPの違いは何ですか?
SAWTはあなたの所得から税を差し引いた源泉徴収義務者を一覧にしたもので、申告書で申請するクレジットを裏付けます。QAPはあなたが税を差し引いた支払先を一覧にしたもので、1601-EQまたは1601-FQを裏付けます。どちらも同じ取引を反対側から記述しているため、一方で正しい行が他方では照合できないことがあります。
BIR Form 2307はSAWTと同じですか?
いいえ。2307は四半期における1つの源泉徴収義務者と支払先の関係に対する証明書です。SAWTは申告書に添付されるそれらの証明書の集約リストです。行の単位は取引先、ATC、月であり、1行につき1証明書ではないため、1つの証明書から複数のアルファリスト行が作成されることがあります。
QAPの期限はいつで、SAWTの期限はいつですか?
QAPは四半期の終了後の翌月末日に1601-EQまたは1601-FQとともに提出します。SAWTには別個の期限はなく、1701Q、1702Q、2550Qなどクレジットを伴う申告書とともに提出します。週末や祝日により期限が移動するため、正確な日付は最新のBIRカレンダーで確認してください。
スキャンまたは撮影した2307からSAWTを作成できますか?
はい。証明書が原本であり、スキャンやスマートフォンでの撮影でもeBIRFormsのPDFと同じ項目が含まれています。まず値をテーブルに抽出し、その後モジュールに入力するか会計システムに取り込んでください。モジュールには構造化された入力または.DATファイルが必要であり、画像を自動で読み取ることはありません。
証明書上では正しく見えるTINがアルファリストで拒否されるのはなぜですか?
末尾5桁を確認してください。14桁のTINには支店コードが含まれるため、本社のTINと支店のTINは最初の9桁が同じでも異なる取引先となります。また、数値セルで失われた先頭のゼロ、特殊文字を含む登録名、ダミーTINがないかも確認してください。あなたの行が証明書と完全に一致している場合、源泉徴収義務者のQAPが異なるTINを保持している可能性があります。
ImageToTable.aiはSAWTを提出したり.DATファイルを生成しますか?
いいえ。証明書の項目をExcel、CSV、JSONに抽出するだけです。.DATファイルの生成、BIR記録との照合、eBIRForms、eFPS、eSubmissionを通じた提出は行いません。これらの手順はAlphalist Data Entry and Validation Moduleとお客様の申告業務に残ります。
申告後に届いた2307はどうすればよいですか?
まだ開いている四半期に無理に押し込まないでください。クレジットにはそれを裏付ける証明書が必要なため、修正申告か正しい申告書での請求という経路になり、適切な経路は申告書とタイミングによって異なります。申告済みの内容を変更する前に、税務顧問またはRDOに確認してください。
証明書は税が源泉徴収されたことを証明します。アルファリストは、クレジットを受ける権利があるという主張であり、その主張は期間、主体、金額が双方で一致して初めて成り立ちます。まず表を作成し、節約できた時間を人の手が必要な照合に使いましょう。