インドの銀行取引明細書をExcelに変換
インドの5億6000万以上の銀行口座からは、ラフ/クロール単位の数値表記、パスワード保護されたPDF、ヒンディー語/デーヴァナーガリー文字、UPI/NEFT/IMPS取引コードなど、特有の課題を持つ明細書が生成されます。正確に変換する方法をご紹介します。

インドでは、ジャンダンヨジャナだけで5億6000万以上の銀行口座が開設され、デジタルバンキングユーザーは2億9500万人以上、UPIを利用する銀行は685行に達し、毎月216億件の取引を処理しています。これらの銀行のほぼすべてがPDF明細書を発行していますが、それぞれ独自のレイアウト、パスワード形式、日付の規則、取引コードシステムを持っています。
インドの銀行取引明細書をExcelに変換するのは、見た目以上に困難です。ラフ/クロール単位の数値システムでは、カンマの配置が西洋式(123,456.78)とは異なります(1,23,456.78)。ほとんどの明細書は、顧客ID、生年月日、口座番号の銀行固有の組み合わせでパスワード保護されています。公営銀行(PSU banks)の明細書には、英語とともにヒンディー語(デーヴァナーガリー文字)が含まれています。また、UPI取引IDやNEFT UTR番号を含む摘要欄は、複数行にわたって折り返されることが多く、標準的な抽出ツールを妨げます。
このガイドでは、インドの主要銀行の明細書フォーマット、パスワードパターン、取引コード、およびそれらをExcel、CSV、またはTally互換フォーマットに変換する際の具体的な課題について説明します。
インドの銀行取引明細書のフォーマット

標準的な列レイアウト
ほとんどのインドの銀行取引明細書は、この列構造を使用しています。
| 列 | 説明 |
|---|---|
| 日付 | 取引日(銀行によってフォーマットが異なる) |
| 決済日 | 資金が実際に決済された日 |
| 摘要 / 説明 / 詳細 | 取引の詳細、コード、相手方 |
| 小切手/参照番号 | 小切手番号または参照番号 |
| 引き出し / debit | 引き落とされた金額 |
| 預け入れ / credit | 入金された金額 |
| 最終残高 | 各取引後の実行残高 |
一部の銀行(SBI、PNB)は、引き出しと預け入れの列を分けています。他の銀行は、Cr/Drの表示がある単一の金額列を使用しています。この不一致が、汎用的な抽出ツールがインドの明細書で苦労する理由の一つです。
銀行別の С日付フォーマット
インドの銀行は、単一の日付フォーマットで合意していません。
| フォーマット | 例 | 使用している銀行 |
|---|---|---|
| DD/MM/YYYY | 2026/03/15 | 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} - バーチャルペイメントアドレス(VPA)付きのUPI取引
- NEFT/{UTR}/{Beneficiary Name} - UTR番号付きのNEFT送金
- RTGS/{UTR}/{Beneficiary Name} - RTGS高額送金
- IMPS/{Ref}/{Name} - IMPS即時送金
- ATM WDL または NWD - ATM引き出し
- CHQ DEP - 小切手預け入れ
- INT CR - 入金された利息
- POS DR - POS(販売時点情報管理)での引き落とし
- NACH - National Automated Clearing House(自動化された全国クリアリングハウス、定期支払い)
- ECS - Electronic Clearing Service(電子クリアリングサービス)
- CMS - Cash Management Services(現金管理サービス)
- DD - Demand Draft(約束手形)
これらの摘要は、PDF内で複数行に折り返されることがよくあります。特にUPI取引(username@banknameのようなVPAを含む)やNEFT送金(16文字のUTR番号と受益者情報を含む)の場合です。標準的な抽出ツールは、折り返された各行を別々の行として扱ってしまうため、日付や金額のない架空の取引が作成されてしまいます。
パスワード保護:インドの銀行ごとに異なる
インドのほとんどの銀行は、顧客にメールで送信する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@DOB(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明細書は、主に英語です。
一般的なヒンディー語の銀行用語
| ヒンディー語(デーヴァナーガリー文字) | 音訳 | 英語 |
|---|---|---|
| खाता | Khata | Account |
| बचत खाता | Bachat Khata | Savings Account |
| चालू खाता | Chalu Khata | Current Account |
| जमा | Jama | Deposit |
| निकासी | Nikaasi | Withdrawal |
| शेष राशि | Shesh Rashi | Balance |
| खाता विवरण | Khata Vivaran | Account Statement |
| ब्याज | Byaaj | Interest |
| दिनांक | Dinank | Date |
| लेनदेन | Lenden | Transaction |
デーヴァナーガリー文字の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 | 口座への入金利息 | 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ヶ月の明細書が推奨される
- 申請前に突然の多額の入金は疑わしく見える
中小企業の簿記
多くのインドの中小企業は、個人銀行口座ですべての取引を行っているため、個人経費と事業経費を区別することが困難です。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と一致しているか
- 開始残高と終了残高が一致しているか
- debitとcreditの合計が正しいか
- 日付が正しい月になっているか(DD/MM vs MM/DDの解釈に注意)
最良の結果を得るためのヒント
デジタル明細書をダウンロードする。 インターネットバンキングのPDFはテキストエンコーディングが完璧なため、抽出精度がほぼ完璧になります。スキャンされた通帳のページは、OCRの制限により精度が低くなります。
適切な出力フォーマットを使用する。 Excelはレビューと分析に最適です。CSVはほとんどのインドの会計ソフトウェアに適しています。XMLはTallyPrime用です。
まずパスワードフォーマットを確認する。 各銀行は異なるパターンを使用しています。開始前にパスワードを用意しておくと時間を節約できます。
Excelでの数値フォーマットを確認する。 インポート後、金額がテキスト(左揃え)ではなく数値(右揃え)として認識されていることを確認します。金額がテキストとして表示される場合は、列を選択して[数値]フォーマットに変換します。
複数口座明細書を慎重に扱う。 一部の銀行では、普通預金口座と当座預金口座を1つの明細書にまとめています。各口座に取引が正しく割り当てられているか確認してください。
無料でお試しください
インドの銀行取引明細書を変換する準備はできましたか? 今すぐPDFをアップロード - PDFSubは、すべての主要なインドの銀行を含む20,000以上の銀行フォーマットをサポートしています。デジタル明細書は、すべてブラウザ内で処理されます。あなたの財務データはデバイスから離れることはありません。
7日間の無料トライアルを開始してください。いつでもキャンセルできます。