インドの銀行取引明細書をExcelに変換
インドの5億6000万以上の銀行口座から生成される取引明細書には、特有の課題があります。それは、ラッキ/クロール単位の数値フォーマット、パスワード保護されたPDF、ヒンディー語（デーヴァナーガリー文字）、およびUPI/NEFT/IMPSの取引コードです。正確に変換する方法をご紹介します。
インドでは、Jan Dhan Yojanaだけでも5億6000万以上の銀行口座が開設されており、デジタルバンキングユーザーは2億9500万人以上、UPIを利用して毎月216億件の取引を処理する銀行が6億8500万行あります。これらの銀行のほぼすべてがPDF形式の取引明細書を発行していますが、それぞれ独自のレイアウト、パスワード形式、日付の慣習、取引コードシステムを持っています。
インドの銀行取引明細書をExcelに変換するのは、見た目以上に困難です。ラッキ/クロールという数値システムでは、西洋のフォーマット（1,23,456.78 vs. 123,456.78）とは異なる方法でコンマが配置されます。ほとんどの明細書は、顧客ID、生年月日、口座番号の銀行固有の組み合わせでパスワード保護されています。公営銀行（PSU banks）の明細書には、英語と並んでヒンディー語（デーヴァナーガリー文字）のテキストが含まれています。また、UPI取引IDやNEFT UTR番号を含む摘要欄は、複数行にまたがって折り返されることが多く、標準的な抽出ツールでは対応できません。
このガイドでは、インドの主要な銀行の明細書フォーマット、パスワードパターン、取引コード、およびそれらをExcel、CSV、またはTally互換フォーマットに変換する際の具体的な課題について解説します。
インドの銀行取引明細書フォーマット
標準的な列レイアウト
ほとんどのインドの銀行取引明細書は、この列構造を使用しています。
| 列 | 説明 |
|---|---|
| 日付 (Date) | 取引日（銀行によりフォーマットが異なる） |
| 処理日 (Value Date) | 資金が実際に処理された日 |
| 摘要 / 説明 / 詳細 (Narration / Description / Particulars) | 取引詳細、コード、相手方 |
| 小切手/参照番号 (Chq/Ref No.) | 小切手番号または参照番号 |
| 引き出し /Debit | 引き落とし額 |
| 預け入れ / Credit | 入金額 |
| 残高 (Closing Balance) | 各取引後の実行残高 |
一部の銀行（SBI、PNB）は、引き出しと預け入れの列を分けています。他の銀行は、Cr/Drの表示がある単一の金額列を使用します。この一貫性のなさが、汎用的な抽出ツールがインドの明細書に苦労する理由の一つです。
銀行別の С形フォーマット
インドの銀行は、単一の日付フォーマットに合意していません。
| フォーマット | 例 | 使用銀行 |
|---|---|---|
| DD/MM/YYYY | 15/03/2026 | SBI、PNB、Canara Bank |
| DD-MM-YYYY | 15-03-2026 | ICICI、ほとんどの公営銀行 |
| DD-MMM-YYYY | 15-Mar-2026 | HDFC Bank |
| DD/MM/YY | 15/03/26 | 一部の古いフォーマットの明細書 |
| DD MMM YYYY | 15 Mar 2026 | Axis Bank |
BIS標準（IS 7900:2001）はISO 8601に準拠したYYYY-MM-DDを推奨していますが、インドの銀行明細書でこれを使用している例はほとんどありません。Excelに変換する際、日付の解析はこれらのすべてのバリエーションを正しく処理する必要があります。日付がMM/DDとして誤解釈されると、取引が数ヶ月ずれてしまう可能性があります。
摘要欄のパターン
摘要欄は、インドの銀行取引明細書が複雑になる場所です。一般的なパターンは次のとおりです。
- UPI/{VPA}/{Name}/{Ref} — UPI取引（仮想決済アドレス付き）
- NEFT/{UTR}/{Beneficiary Name} — NEFT送金（UTR番号付き）
- RTGS/{UTR}/{Beneficiary Name} — RTGS高額送金
- IMPS/{Ref}/{Name} — IMPS即時送金
- ATM WDL または NWD — ATM引き出し
- CHQ DEP — 小切手預け入れ
- INT CR — 利息 credited
- POS DR — POS（Point of Sale）での引き落とし
- NACH — National Automated Clearing House（定期支払い）
- ECS — Electronic Clearing Service
- CMS — Cash Management Services
- DD — Demand Draft（銀行発行の手形）
これらの摘要は、特にUPI取引（username@banknameのようなVPAを含む）やNEFT送金（16文字のUTR番号と受取人詳細を含む）の場合、PDF内で複数行に折り返されることがよくあります。標準的な抽出ツールは、折り返された各行を別々の行として扱ってしまうため、日付や金額のない架空の取引が作成されます。
パスワード保護：インドの銀行はそれぞれ異なる
インドのほぼすべての銀行は、顧客にメールで送信するPDF明細書にパスワードを設定しています。パスワード形式は銀行ごとにユニークです。
| 銀行 | パスワード形式 | 例 |
|---|---|---|
| SBI (モバイルバンキング) | 11桁の口座番号 | 12345678901 |
| SBI (メール) | 携帯電話番号の下5桁 + 生年月日 (DDMMYY) | 56789010190 |
| HDFC Bank (口座) | 顧客ID | 12345678 |
| HDFC Bank (クレジットカード) | 名前の最初の4文字（大文字） + カード下4桁 | SWAT5692 |
| ICICI Bank | 口座名義の最初の4文字 + 生年月日 (DDMM) | SWAT1801 |
| Axis Bank | 名前の最初の4文字（大文字） + 生年月日 (DDMM) | RAJA0508 |
| PNB | 9桁の顧客ID（英数字） | ABC123456 |
| Kotak Mahindra | CRN（顧客リレーションシップ番号） | 9876543210 |
| Bank of Baroda | 名前の最初の4文字（小文字） + 生年月日 (DDMM) | raje0508 |
| Bank of India | 名前の最初の4文字（小文字） + 生年月日 (DDMM) | anan1606 |
| Canara Bank | 顧客ID（CIF番号） | 9876543210 |
| Union Bank | 名前フォーマット + 生年月日 | RAJA05081990 |
| IDBI Bank | 顧客ID | 1234567890 |
| Yes Bank | 顧客ID + 完全な生年月日 (DDMMYYYY) | 123456789001011990 |
| IndusInd Bank | 名前の最初の4文字（大文字） + 生年月日 (DDMM) | RAJA0508 |
| Central Bank of India | CustomerID@生年月日 (DDMMYYYY) | 9029080134@18031998 |
| Indian Bank | 完全な銀行口座番号 | (全桁の番号) |
PDFSubの銀行取引明細書コンバーターには、ロック解除ステップが含まれています。パスワードを一度入力すれば、コンバーターが残りを処理します。パスワードはブラウザ内でローカルに使用され、サーバーに送信されることはありません。
インドの数値システム：ラッキとクロール
インドの数値システムは、最初の3桁以降、数字のグループ化が西洋システムとは異なります。
| 金額 | インド形式 | 西洋形式 |
|---|---|---|
| 1千 | 1,000 | 1,000 |
| 1万 | 10,000 | 10,000 |
| 1ラッキ | 1,00,000 | 100,000 |
| 10ラッキ | 10,00,000 | 1,000,000 |
| 1クロール | 1,00,00,000 | 10,000,000 |
コンマのパターンは、右から3桁ごとに最初のコンマがあり、その後2桁ごとにコンマが配置されます。
抽出における重要性： 西洋のコンマ配置（3桁ごと）を期待するコンバーターは、インド形式の数値を誤って解析します。「1,23,456.78」（1ラッキ23千）という金額が、「123,456.78」または「1,234,567.8」と誤って解析される可能性があります。どちらも間違いです。
PDFSubはインドの数値フォーマットを正しく処理し、コンマの配置に関係なく実際の数値値を保持します。
Excelのヒント： Excelでインド形式の数値を表示するには、システムロケールを英語（インド）に変更するか、カスタム数値フォーマットを使用します：[>=10000000]##\,##\,##\,##0;[>=100000] ##\,##\,##0;##,##0
ヒンディー語およびバイリンガル明細書
ヒンディー語が表示される場所
RBI（インド準備銀行）の顧客サービスに関するマスターサーキュラーでは、すべての顧客向け資料はヒンディー語、英語、および地域言語で利用可能であることが義務付けられています。実際には以下のようになります。
- ヘッダーはヒンディー語と英語の両方で表示される場合があります（例：「खाता विवरण / Account Statement」）。
- 銀行名と支店名は、公営銀行（PSU）の明細書にヒンディー語で表示されます。
- 摘要欄は、ほぼ常に英語です（NEFT、UPI、IMPSなどの取引コードは英語です）。
- 地方の政府/公営銀行の通帳には、ヒンディー語のみのヘッダーが含まれる場合があります。
- インターネットバンキングからのデジタルPDF明細書は、主に英語です。
一般的なヒンディー語の銀行用語
| ヒンディー語 (デーヴァナーガリー文字) | transliteration | 英語 |
|---|---|---|
| खाता | Khata | 口座 |
| बचत खाता | Bachat Khata | 普通預金口座 |
| चालू खाता | Chalu Khata | 当座預金口座 |
| जमा | Jama | 預け入れ |
| निकासी | Nikaasi | 引き出し |
| शेष राशि | Shesh Rashi | 残高 |
| खाता विवरण | Khata Vivaran | 口座明細書 |
| ब्याज | Byaaj | 利息 |
| दिनांक | Dinank | 日付 |
| लेनदेन | Lenden | 取引 |
デーヴァナーガリー文字のOCR課題
ヒンディー語のテキストが含まれるスキャンされた明細書は、特定のOCR課題を提示します。
- 複雑な文字構造 — デーヴァナーガリー文字には、ラテン文字よりもセグメント化が難しい合字があります。
- 印刷されたデーヴァナーガリー文字の精度 — 明瞭な印刷文字で90〜95％。
- 手書きのヒンディー語の精度 — 明瞭なサンプルで70〜85％。
- 複数スクリプトの混在 — デーヴァナーガリー文字とラテン文字を組み合わせた明細書は、両方のスクリプトを同時に処理できるOCRシステムが必要です。
- レガシーフォントエンコーディング — Kruti DevのようなUnicode以前のフォントは、ラテン文字のコードポイントを使用してデーヴァナーガリー文字をエンコードするため、OCRエラーが発生します。
PDFSubは、ヒンディー語（デーヴァナーガリー文字）を含む130以上の言語をサポートしています。デジタルPDF明細書（インターネットバンキングからダウンロードするタイプ）の場合、OCRなしで抽出できます。テキストはすでにPDF内にエンコードされています。OCRは、スキャンまたは写真撮影された明細書にのみ必要です。
取引コードリファレンス
インドの銀行取引明細書では、さまざまな決済システムに特定の略語が使用されています。
| コード | 正式名称 | 説明 | 一般的なフォーマット |
|---|---|---|---|
| UPI | Unified Payments Interface | モバイル即時決済 | UPI/{VPA}/{Name}/{Ref} |
| NEFT | National Electronic Funds Transfer | バッチ処理による送金 | NEFT/{UTR}/{Name} |
| RTGS | Real Time Gross Settlement | 高額リアルタイム送金（最低20万ルピー） | RTGS/{UTR}/{Name} |
| IMPS | Immediate Payment Service | リアルタイム送金（金額問わず） | IMPS/{Ref}/{Name} |
| NACH | National Automated Clearing House | 一括/定期支払い（EMI、保険料など） | NACH/{Mandate}/{Name} |
| ECS | Electronic Clearing Service | 旧一括支払いシステム | ECS/{Ref} |
| ATM WDL | ATM Withdrawal | ATMでの現金引き出し | ATM WDL/{Location} |
| NWD | Non-Home Branch Withdrawal | 別の銀行でのATM引き出し | NWD/{Bank}/{Location} |
| CHQ DEP | Cheque Deposit | 小切手預け入れ | CHQ DEP/{Chq No} |
| POS | Point of Sale | 加盟店でのカード決済 | POS/{Merchant}/{City} |
| INT CR | Interest Credit | 口座への利息 credited | INT CR |
| CMS | Cash Management Services | 法人向け現金管理サービス | CMS/{Ref} |
| DD | Demand Draft | 銀行発行の手形 | DD/{No}/{Name} |
UTR（Unique Transaction Reference）フォーマット：
- NEFT：16文字のコード（銀行コード + 日付 + シリアル番号）
- RTGS：22文字のコード（銀行コード + 完全な日付 + シリアル番号）
- IMPS：12桁の数値参照番号
- UPI：VPA（Virtual Payment Address）付きの可変フォーマット
これらのコードを理解することで、抽出されたデータが取引タイプを正しく分類しているかを確認できます。
銀行固有の明細書の特徴
SBI (State Bank of India)
資産で23％、融資と預金で25％の市場シェアを持つインド最大の銀行。
- レイアウト： 引き出しと預け入れの列が分かれている。
- 日付フォーマット： DD/MM/YYYY
- パスワード（モバイルバンキング）： 11桁の口座番号
- パスワード（メール）： 携帯電話番号の下5桁 + 生年月日 (DDMMYY)
- ヘッダー： バイリンガル（ヒンディー語 + 英語）
- 摘要： 内部コードで省略されることが多い。
HDFC Bank
時価総額で最大の民間銀行で、9,100以上の支店を持つ。
- レイアウト： 引き出しと預け入れの列が分かれている。
- 日付フォーマット： DD-MMM-YYYY（例：15-Mar-2026）
- パスワード（口座）： 顧客ID
- パスワード（クレジットカード）： 名前の最初の4文字（大文字） + カード下4桁
- ヘッダー： 英語のみ。
- 摘要： 受取人のフルネームを含む、比較的詳細。
ICICI Bank
6,613支店を持つ、2番目に大きい民間銀行。
- レイアウト： 引き出しと預け入れの列が分かれている。
- 日付フォーマット： DD-MM-YYYY
- パスワード： 口座名義の最初の4文字 + 生年月日 (DDMM)
- ヘッダー： 英語のみ。
- 摘要： 取引参照番号を含む。
Axis Bank
3番目に大きい民間銀行。
- レイアウト： 引き出しと預け入れの列が分かれている。
- 日付フォーマット： DD MMM YYYY（スペース区切り）
- パスワード： 名前の最初の4文字（大文字） + 生年月日 (DDMM)
- ヘッダー： 英語のみ。
PNB (Punjab National Bank)
11,000以上の支店を持つ、2番目に大きい公営銀行。
- レイアウト： 引き出しと預け入れの列が分かれている。
- 日付フォーマット： DD/MM/YYYY
- パスワード： 9桁の顧客ID（英数字）
- ヘッダー： バイリンガル（ヒンディー語 + 英語）
- 摘要： 支店レベルの取引ではヒンディー語が含まれることが多い。
インドの銀行取引明細書変換のユースケース
GSTコンプライアンスと申告
GST（物品・サービス税）制度下では、GSTの照合は事業者にとって義務です。銀行取引明細書は、以下のための補助書類として機能します。
- GSTR-2A/2Bの照合 — 購入/販売データをサプライヤーの記録と照合する。
- 仕入税額控除（Input Tax Credit）の請求 — 銀行手数料に支払われたGSTを確認する。
- GSTR-9C — GST申告と監査済み財務諸表を比較する年次照合明細書。
- CGST規則第54条(2) — 銀行が税務インボイスを発行しない場合、銀行取引明細書がインボイスとみなされる。
明細書をExcelに変換することで、取引日、金額、相手方詳細を照合し、月次のGST照合を効率化できます。
所得税申告書の準備
公認会計士（CA）は、現金出納帳、元帳、仕訳帳、銀行取引明細書、売上/購入インボイスを監査します。第44AB条に基づき、
- 事業売上が1クロール（約100万ドル）を超える場合（現金取引が5％未満の場合は10クロールまで）は、税務監査が必要です。
- 専門職の総収入が50ラッキ（約5万ドル）を超える場合は、税務監査が必要です。
- 第271B条に基づく罰金： 違反があった場合、1ラッキまたは売上の0.5％（いずれか低い方）。
整理されたExcel形式の銀行取引明細書は、監査準備時間を大幅に短縮し、CAが収入、支出、キャッシュフローを効率的に検証するのに役立ちます。
TDS/TCSの追跡
年間の利息収入が40,000ルピー（高齢者は50,000ルピー）を超える場合、銀行はTDS（源泉徴収税）を差し引きます。銀行取引明細書をExcelに変換することで、以下のことが可能になります。
- TDS控除額をForm 26ASおよび**Annual Information Statement (AIS)**と照合する。
- 銀行が差し引いたTDSとTRACESの記録との間の不一致を特定する。
- 請負業者/専門家へのTDS（第194C条、194J条）および購入に対するTCSを追跡する。
ローン申請
すべてのインドの主要銀行は、収入証明として過去6ヶ月間の銀行取引明細書をローン申請に要求します。自営業の借り手は、現在の口座明細書やCC/OD（当座貸越）ファシリティの明細書などの追加書類が必要です。
Excelへの変換は、申請者が自身の財務データをレビューし、異常を特定し、明細書が貸付業者の要件を満たしていることを確認するのに役立ちます。
ビザ申請
ほとんどのビザ申請では、資金証明として現在の銀行取引明細書が必要です。
- 最低残高は通常150,000ルピーから500,000ルピー（渡航先国によって異なる）。
- 過去6ヶ月間の明細書が推奨される。
- 申請前に突然多額の入金があると、疑わしく見える可能性がある。
中小企業（SME）の簿記
インドの中小企業の多くは、個人銀行口座ですべての取引を行っており、個人支出と事業支出を区別することが困難です。PDF明細書をExcelに変換することで、年末に慌てるのではなく、定期的に分類と照合を行うことができます。
会計ソフトウェアとの互換性
TallyPrime（インドで最も広く使用されている）
TallyPrime 7.0は、145以上の銀行の銀行取引明細書インポートをサポートしています。
- 推奨インポート形式： XML（構造化データに最も信頼性が高い）。
- 受け入れられる形式： Excel、CSV、MT940。
- 主な要件： XMLの銀行口座名は、Tallyの銀行元帳名と一致する必要があります。
- 自動照合： インポートされた取引をTallyの既存のレコードと照合します。
- 伝票日付の要件： アクティブな会計年度内に収まっている必要があります。
ワークフロー： PDFSubで銀行取引明細書をExcelに変換 → 列をTallyの期待される構造にマッピング → XMLとしてエクスポート → TallyPrimeにインポート。
Zoho Books
インドの中小企業やスタートアップに人気があります。
- サポートされている形式： CSV、TSV、OFX、QIF、CAMT.053。
- サポート： 単一列（タイプ付き金額）と二重列（預け入れ/引き出し別々）の両方の形式。
- 列マッピング： インポート中に設定可能。
QuickBooks India
- サポートされている形式： CSV（3列または4列）。
- 日付フォーマット： DD/MM/YYYYを推奨。
- 要件： 通貨記号を削除、千単位の区切り文字を削除、英語テキスト、350KB未満のファイル、アップロードあたり最大1,000行。
Vyapar
インドの中小企業に人気の請求および会計アプリ。
- サポートされている形式： Excel、CSV。
Busy Accounting
インドで人気のあるデスクトップ会計ソフトウェア。
- サポートされている形式： Excel、CSV。
インポート形式の概要
| ソフトウェア | Excel | CSV | XML | OFX | QIF |
|---|---|---|---|---|---|
| TallyPrime | はい | はい | はい（推奨） | いいえ | いいえ |
| Zoho Books | いいえ | はい | いいえ | はい | はい |
| QuickBooks India | いいえ | はい | いいえ | いいえ | いいえ |
| Vyapar | はい | はい | いいえ | いいえ | いいえ |
| Busy Accounting | はい | はい | いいえ | いいえ | いいえ |
PDFSubは、Excel、CSV、TSV、JSON、OFX、QBO、QFX、QIFにエクスポートします。これにより、インドの主要な会計プラットフォームすべてに対応できます。
データプライバシー：DPDP法とブラウザベース処理
インドのデジタル個人データ保護法（DPDP Act 2023）
インド初の包括的なデジタルプライバシー法が2023年8月に制定され、DPDP規則2025が2025年11月に通知されました。完全な遵守は2027年5月13日までに予定されています。
7つの基本原則：
- 同意と透明性 — データ処理者は、処理の詳細を事前に開示する必要があります。
- 目的制限 — データは明示された目的にのみ使用されます。
- データ最小化 — 必要なものだけを収集します。
- 正確性 — データを正確かつ最新の状態に保ちます。
- 保存期間制限 — 必要な期間を超えて保持しません。
- セキュリティ対策 — 侵害から保護します。
- アカウンタビリティ — 組織はコンプライアンスに責任を負います。
RBIのデータローカライゼーション
RBIは、すべての決済システムデータをインド国内のみに保存することを義務付けています。これは、銀行取引明細書を処理するあらゆるツール、特にクラウドベースのツールがインド国外のサーバーを経由する可能性がある場合に特に重要です。
ブラウザベース処理の重要性
PDFSubがブラウザで銀行取引明細書を処理する場合：
- PDFはデバイスからブラウザのメモリに読み込まれます。
- 抽出はローカルで行われます — 日付、摘要、金額が特定されます。
- 出力ファイル（Excel、CSVなど）がブラウザで生成されます。
- 結果をデバイスに直接ダウンロードします。
データはどのサーバーにも送信されません。 銀行取引明細書はデバイスから離れることはなく、以下の原則に準拠しています。
- DPDP法 データ最小化 — データ収集は行われません。
- RBI データローカライゼーション — データはインド国内のデバイス上に留まります。
- AICPA/CA専門基準 — 第三者への開示はありません。
これを検証できます。明細書を処理中にブラウザの開発者ツール（F12 → Networkタブ）を開いてください。金融データを含むアウトバウンドリクエストはゼロです。
一般的な課題と解決策
複数行にわたる摘要の折り返し
問題： インドの銀行取引明細書の摘要は、しばしば2〜3行に折り返されます。日付、金額、残高が含まれるのは最初の行のみです。標準的なツールは、各行を個別の取引として扱います。
解決策： PDFSubの抽出エンジンは、日付と金額がない行を特定することで複数行の摘要を検出し、親取引にマージします。結果として、取引ごとに1つのクリーンな行が作成されます。
ラッキ/クロール数値の解析
問題： 西洋中心のツールは、3桁ごとにコンマを期待します。インドのフォーマット（1,23,456.78）は誤解釈されます。
解決策： PDFSubはインドの数値フォーマットを認識し、正しい数値値を保持します。Excel出力では、数値は実際の数値値として保存され、合計、並べ替え、分析が可能です。
パスワード保護されたPDF
問題： インドの各銀行は異なるパスワード形式を使用しています。ユーザーは、自分の銀行がどの組み合わせを使用しているかを思い出すのに時間を浪費します。
解決策： このガイドのパスワード参照表を使用してください。PDFSubのコンバーターにはパスワードロック解除ステップが含まれています — 一度入力すれば、変換を続行できます。パスワードはブラウザ内でローカルに処理されます。
日付フォーマットの不一致
問題： DD/MM/YYYY、DD-MMM-YYYY、DD MMM YYYY — 各銀行が独自のフォーマットを使用しています。Excelは、ロケールが一致しない場合、日付を誤解釈する可能性があります。
解決策： PDFSubは抽出中に日付を正規化します。Excel出力では、日付は一貫したフォーマットの適切な日付値として保存され、ロケール関連の誤解釈を防ぎます。
ヒンディー語と英語の混在テキスト
問題： 公営銀行の明細書には、ヒンディー語のヘッダーや、場合によってはヒンディー語の摘要が含まれます。英語のみを期待するツールは、これらのセクションを解析できない場合があります。
解決策： PDFSubは、ヒンディー語を含む130以上の言語をサポートしています。デジタルPDF（インターネットバンキングからダウンロードするタイプ）には、ファイルに直接エンコードされたテキストが含まれており、OCRは不要です。ヒンディー語と英語の両方のテキストが正しく抽出されます。
ステップバイステップ：インドの銀行取引明細書を変換する
ステップ1：明細書をダウンロードする
銀行のインターネットバンキングポータルにログインし、PDF明細書をダウンロードします。デジタル明細書は、スキャンされた通帳のページよりも正確です。
ステップ2：パスワードをメモする
このガイドのパスワード表を参照して、お使いの銀行のフォーマットを確認してください。一般的なパターンは次のとおりです。
- 顧客ID（HDFC、Canara、IDBI）
- 名前略称 + 生年月日（ICICI、Axis、Bank of Baroda）
- 口座番号（SBIモバイルバンキング、Indian Bank）
ステップ3：アップロードして変換する
- PDFSubの銀行取引明細書コンバーターにアクセスします。
- PDF明細書をアップロードします。
- プロンプトが表示されたらパスワードを入力します。
- 出力フォーマット（Excel、CSV、または会計ソフトウェアの推奨フォーマット）を選択します。
- 変換されたファイルをダウンロードします。
ほとんどの明細書の場合、プロセス全体は30秒未満で完了します。ファイルはブラウザで処理され、サーバーにアップロードされることはありません。
ステップ4：会計ソフトウェアにインポートする
TallyPrimeの場合： Excelファイルを開き、列をTallyの期待されるフィールドにマッピングし、XMLとしてエクスポートしてからTallyPrimeにインポートします。
Zoho Booksの場合： Banking → Import Statement を通じてCSVファイルを直接アップロードします。インポート中に列をマッピングします。
QuickBooksの場合： Banking → Upload Transactions を通じてCSVファイルをアップロードします。日付フォーマットがDD/MM/YYYYと一致していることを確認してください。
ステップ5：検証する
常に以下を確認してください。
- 取引数がソースPDFと一致しているか。
- 開始残高と終了残高が一致しているか。
- 合計引き出し額と預け入れ額が正しいか。
- 日付が正しい月になっているか（DD/MM vs. MM/DDの解釈に注意）。
最良の結果を得るためのヒント
デジタル明細書をダウンロードしてください。 インターネットバンキングのPDFは完璧なテキストエンコーディングを持っており、抽出精度はほぼ完璧です。スキャンされた通帳のページは、OCRの制限により精度が低くなります。
適切な出力フォーマットを使用してください。 Excelはレビューと分析に最適です。CSVはほとんどのインドの会計ソフトウェアに適しています。XMLはTallyPrime用です。
まずパスワード形式を確認してください。 各銀行は異なるパターンを使用しています。開始前にパスワードを用意しておくと、時間を節約できます。
Excelでの数値フォーマットを確認してください。 インポート後、金額がテキスト（左揃え）ではなく数値（右揃え）として認識されていることを確認してください。金額がテキストとして表示される場合は、列を選択して数値フォーマットに変換してください。
複数口座の明細書を慎重に扱ってください。 一部の銀行では、普通預金口座と当座預金口座を1つの明細書にまとめています。取引が各口座に正しく割り当てられているか確認してください。
無料でお試しください
インドの銀行取引明細書を変換する準備はできましたか？ 今すぐPDFをアップロード — PDFSubは、インドのすべての主要銀行を含む20,000以上の銀行フォーマットをサポートしています。デジタル明細書は完全にブラウザ内で処理されます。あなたの財務データはデバイスから離れることはありません。
7日間の無料トライアルを開始してください。いつでもキャンセルできます。