How to Extract Japanese Invoice (請求書) Data to Excel
for Accounts Payable and Tax Filing

What a Japanese Invoice Contains — Field by Field

Japanese invoices operate under a legal framework that makes their field structure both more standardized and more detailed than a typical Western invoice. Since October 2023, the Qualified Invoice System (インボイス制度, officially the 適格請求書等保存方式) requires that every invoice used for input tax credit claims carry a Qualified Invoice registration number — a "T" followed by 13 digits — and separately state the consumption tax amounts by rate category (10% standard and 8% reduced). Below the legal requirements, decades of domestic business convention add payment-terms syntax and bank-transfer routing that no international extraction tool was trained to parse.

Here is the full field structure an AP department actually works with when processing a seikyūsho:

The field structure is not guesswork — the Cabinet Office's official overview of the Qualified Invoice system lists the six mandatory items that every invoice (インボイス) must contain. But the extraction task goes beyond the six mandatory items. The fields that consume the most manual AP time — bank transfer details, payment terms parsing, withholding tax — are not legally required on the invoice at all. They are included by convention, and they are the fields that make a Japanese invoice processing workflow different from an American or European one.

Why Generic Invoice Extraction Breaks on Japanese Invoices

Most AI invoice extraction tools were trained on English-language invoice datasets — US and EU formats where the fields are "Invoice Number," "Due Date," "Total," and "Vendor." Drop a Japanese invoice into one of these tools and three things happen.

First, the supplier's bank transfer details (振込先) are ignored or misread. A Japanese invoice lists the bank name (e.g., 三菱UFJ銀行), branch (e.g., 新宿支店), account type (普通), and account number as separate labeled fields — but a generic extraction engine sees four text strings near the bottom of the page and has no column definition for "bank transfer details," so it either skips them or concatenates them into one garbled field. The AP team still has to open each PDF and type the bank details into the payment system.

Second, the payment terms (支払条件) are read as an opaque text string when they encode two calculable values. "20日締翌月末払い" is not decorative text. It tells the AP team that the billing period closes on the 20th — transactions before that date are this month's obligation, transactions after it belong to next month — and that payment is due by the end of the following month. A generic extractor outputs the string unchanged. An extraction that understands Japanese payment conventions splits it into Settlement Day: 20 and Payment Lag: 1 month — two structured values that a payment calendar formula can consume.

Third, the consumption tax breakdown and withholding tax classification have no equivalent in Western extraction schemas. A tax field on a US invoice is a single sales tax line. On a Japanese invoice, there are potentially three tax-relevant fields: the 10% consumption tax subtotal, the 8% reduced-rate consumption tax subtotal (for mixed-item invoices), and — if the supplier is a qualifying professional — a withholding tax amount or classification mark. A generic extraction that flattens all tax fields into one number makes the AP team undo the flattening during verification.

How to Extract Invoice Data to Excel — Step by Step

The workflow that replaces manual invoice-to-AP-spreadsheet transcription mirrors the approach used for purchase orders but with a different column schema — the fields unique to invoices — and a different downstream pipeline into the bank payment process rather than the PO-matching process. The three-stage workflow is defined once and applies to every supplier, every invoice format, and every subsequent month-end batch.

The Fields Where Generic Invoice Extraction Breaks — and How to Handle Them

Four data points on a Japanese invoice resist automatic extraction more than the rest — not because the OCR cannot read the characters, but because each field carries embedded business logic that must be preserved as structured data rather than flattened into a text string.

Bank Transfer Details (振込先) — four fields that become a payment batch

The bank transfer details block is the single most repetitive data entry task in Japanese AP. An AP clerk takes the invoice, opens the internet banking screen, and types four values: bank name, branch name, account type, and account number — the same four values already recorded in the accounting software's supplier master. When sixty invoices arrive at month-end, that is sixty rounds of retyping four fields per invoice — 240 individual data entries that add no new information, only duplicate information from one system to another.

The extraction approach captures each of the four fields into its own column: Bank Name (振込先銀行名), Branch Name (支店名), Account Type (口座種別 — 普通 or 当座), and Account Number (口座番号). For ゆうちょ銀行 transfers, where the account reference uses a 記号-番号 format (e.g., 記号12345 番号6789012) that differs from the 7-digit transfer account number required by commercial bank systems, an Inferred Column can convert the Japan Post format during extraction: define a column like Transfer Account Number (if ゆうちょ, convert 記号-番号 to 7-digit format per Japan Post Bank conversion rule). The AI applies the conversion during extraction so the AP team receives the account number in transfer-ready format.

With bank details in structured columns, the next step — creating a payment batch file for the bank — becomes a spreadsheet operation rather than a re-typing exercise. The Bank Name, Branch Name, Account Type, Account Number, and Account Holder columns from the extraction form the input to a CSV-formatted batch payment file that the bank's internet banking system accepts as an upload.

Payment Terms (支払条件) — from compound text to settlement day and payment lag

Japanese payment terms are a compact syntax that the AP team reads in one glance but that resists formulaic extraction. "20日締翌月末払い" encodes two decisions: the billing period closes on the 20th of each month, and payment is due by the end of the following month. A Computed Column — a column whose value the AI calculates during extraction — splits this into two structured fields: Settlement Day (from Payment Terms: if "20日締" then 20, if "月末締" then 31, if "10日締" then 10) and Payment Lag Months (from Payment Terms: if "翌月末払い" then 1, if "翌々月末払い" then 2).

The settlement day is operational, not cosmetic. An invoice dated March 18 under 20日締 terms falls into the March billing period — payment is due by the end of April, and the expense belongs to the current fiscal year if the company closes books on March 31. An invoice dated March 22 under the same 20日締 terms falls into the April billing period — payment is due by the end of May, and the expense belongs to the next fiscal year. The settlement day, not the invoice date or the calendar month boundary, determines fiscal-year classification. The same payment terms logic is covered in detail in the guide to extracting Japanese purchase order data, which carries the same payment terms fields from the procurement side.

Consumption Tax (消費税) — dual-rate split that the tax return needs as structured input

Japan's consumption tax system uses two rates — 10% standard and 8% reduced — and the qualified invoice must state the taxable base and tax amount for each rate category separately. The AP team verifying an invoice before payment needs to confirm that the rate-grouped totals on the invoice match what the accounting system expects. The tax team filing the consumption tax return needs the 10% and 8% totals as input data for the return calculation.

An Inferred Column handles the classification during extraction: Tax Rate (from Item Description: food/beverage items → 8% Reduced, standard goods/services → 10% Standard, explicitly export-related → Tax-Exempt). The AI reads each line item description, applies Japan's dual-rate rules, and populates the Tax Rate column. The output spreadsheet arrives with every line pre-classified — 10% Standard subtotal and 8% Reduced subtotal are computable from the extracted data rather than requiring a separate classification pass. For mixed-item invoices — office supplies (10%) shipped alongside packaged beverages (8%) — the classification per line is the only way to verify that the invoice's rate-grouped totals are correct without reopening each invoice PDF.

Withholding Tax (源泉徴収) — when the payer must deduct before remitting

Japan's withholding tax system requires the payer to deduct income tax at source when making payments to certain professional service providers — tax accountants (税理士), certified public accountants (公認会計士), lawyers (弁護士), judicial scriveners (司法書士), designers (デザイナー), writers (著作家), and several other categories defined under Article 204 of the Income Tax Act (所得税法). The withholding rate is generally 10.21% of the payment amount. The payer remits the withheld amount to the tax office and pays the supplier the remaining 89.79%.

An invoice that carries a withholding tax classification — often marked as 源泉徴収あり or by showing a separate 「源泉徴収額」 line — changes the payment calculation. The AP team must subtract the withholding from the invoice total, pay the net amount to the supplier, and book the withheld amount as a separate tax deposit liability. If the withholding is not captured during extraction, the AP team must re-examine each qualifying invoice, calculate the withholding manually, and adjust the payment — a per-invoice arithmetic step that, across sixty invoices, consumes measurable AP time.

A column defined as Withholding Tax Classification (check if invoice mentions 源泉徴収; output "Applicable" if the supplier is a qualifying professional and withholding is indicated, otherwise "Not Applicable") flags which invoices require the deduction. A Computed Column like Net Payment Amount (if withholding applicable: Total × 0.8979; otherwise: Total) calculates the actual transfer amount directly.

Getting Extracted Invoice Data Into Japanese Accounting Software

The output of an extraction job is a structured spreadsheet. The destinations are the accounting software where purchase journal entries are recorded and the bank system where payments are executed. Every major Japanese accounting platform accepts structured data imports — the bottleneck has always been the step upstream of the import: getting invoice data out of supplier PDFs and into structured form.

Yayoi (弥生会計) — the market leader in Japanese SME accounting — imports purchase ledger data via CSV. Extracted invoice columns map directly: Invoice Number → 伝票番号, Supplier → 仕入先, Date → 日付, Total → 金額. The consumption tax amounts by rate category feed into Yayoi's tax reporting module. For companies also using Yayoi Sales (弥生販売), the companion purchasing module, invoice data links to the corresponding PO records — creating the document chain that the three-way match (三点照合) requires.

freee — the cloud accounting platform used by over 70,000 SMEs — supports automatic journal entry generation (自動仕訳) from CSV import. The Qualified Invoice registration number extracted alongside each invoice line flows into freee's invoice compliance check, and the rate-grouped consumption tax amounts populate the consumption tax return calculation that freee generates automatically. The bank transfer details — already in separate columns from extraction — feed into freee's payment module for bank batch file creation.

MoneyForward Cloud Accounting (マネーフォワード クラウド会計) — with the largest number of financial institution API connections in Japan (2,451+) — imports purchase invoice data into its purchase management module. The platform's automatic bank reconciliation matches payment records against bank feeds, and extracted invoice data with consumption tax breakdown supports MoneyForward's dual-rate tax reporting.

Kanjo Bugyo (勘定奉行) — OBC's suite for mid-size companies (annual revenue ¥500M–5B) — supports batch CSV import of purchase invoice data with department-level cost allocation (部門別原価管理). If invoices carry department codes or cost center references, those fields flow into Kanjo Bugyo's segmented P&L reporting automatically.

The common thread: once invoice data is in structured columns, the import into any of these platforms is a file upload. The step that currently takes hours — typing sixty invoices' worth of bank details, tax amounts, and payment terms into the accounting system — becomes a verification exercise: check the extracted data, confirm the outliers, and import. For the same extraction approach applied to the procurement side of the matching workflow, see the step-by-step guide to extracting Japanese purchase order data to Excel. For the banking counterpart — extracting transaction records that appear alongside invoice payments — the Japanese bank passbook extraction guide covers the complete passbook-to-spreadsheet workflow.

FAQ

Can the extraction read handwritten invoices from small suppliers?

Yes. Many smaller Japanese suppliers — local service providers, individual contractors, rural manufacturers — still issue handwritten invoices (手書き請求書) on pre-printed stationery, with amounts written in ballpoint pen and stamped with the company seal. The AI model reads handwritten kanji and numerals, including the abbreviated notation common on manual invoices (㈱ for 株式会社, 〒 as the postal mark prefix, No. for number). For heavily degraded scans or fax copies, scanning at 300 dpi or higher is recommended. Spot-checking difficult characters — particularly handwritten bank account numbers where a misread digit means a failed transfer — is prudent for handwritten documents.

How does extraction handle the ゆうちょ銀行 account number format?

Japan Post Bank (ゆうちょ銀行) uses a 記号-番号 format (e.g., 記号12345 番号6789012) that differs from the 7-digit account numbers used by commercial banks. When transferring from a commercial bank to a Japan Post account, the 記号-番号 must be converted to a 7-digit transfer account number. An Inferred Column can perform this conversion during extraction: define the column logic to detect ゆうちょ銀行 as the bank name, parse the 記号-番号 fields, and output the converted 7-digit number. The Japan Post Bank website publishes the conversion rule — essentially, the 記号 digits map to the first portion of the transfer account number and the 番号 digits (minus the final check digit for 8-digit numbers) map to the remainder.

What happens if the Qualified Invoice registration number (インボイス登録番号) is missing?

If the supplier is not registered as a Qualified Invoice Issuer (適格請求書発行事業者), their invoice will not carry a registration number. In this case, the buyer cannot claim full input tax credit on the purchase — but transitional measures allow partial deduction. From October 2023 through September 2026, 80% of the input tax is creditable. From October 2026 through September 2029, 50% is creditable. After September 2029 or 2031 (depending on the 2026 tax reform extension), zero. During the transitional period, the AP team must flag non-qualified invoices separately because the reduced credit must be calculated on a different basis from qualified invoices. An extraction column that captures the registration number — or notes its absence — provides the data needed to route each invoice to the correct tax treatment.

Can the same extraction handle both tax-inclusive (税込) and tax-exclusive (税抜) invoices?

Yes, but the column definition should specify the desired output format. If some suppliers issue tax-inclusive invoices (内税) and others issue tax-exclusive invoices (外税), adding a Computed Column resolves the normalization during extraction. For example: Line Amount Tax-Exclusive (if unit prices are tax-inclusive, divide by 1.1 for 10% items or 1.08 for 8% items; otherwise use as-is). The AI reads the document context — including any notation like 税込 or 税抜 on the invoice — to determine the tax treatment and normalize the output. All line amounts in the spreadsheet arrive on a consistent tax-exclusive basis, ready for comparison against the PO.

How does the withholding tax (源泉徴収) column interact with the payment amount calculation?

The withholding tax is a deduction the payer makes before remitting to the supplier. The invoice total is the gross billing amount; the amount the supplier receives is the total minus the withholding. A Computed Column configured as Net Payment Amount (if Withholding Tax Classification = "Applicable": Total × 0.8979; otherwise: Total) outputs the actual transfer amount for each invoice. The withheld amount — the difference between Total and Net Payment — is owed to the tax office (税務署) as a separate deposit. The AP ledger should carry three columns per withholding-eligible invoice: Gross Amount (the invoice total), Withholding Amount (the tax deduction), and Net Payment (the transfer amount). The extraction produces all three, so the payment batch file and the tax deposit schedule are built from the same source data.

Does this work for invoices with mixed consumption tax rates on the same document?

Yes. A single Japanese invoice can carry items at 10% standard rate, 8% reduced rate, and tax-exempt. The Qualified Invoice system requires the invoice to separately state the taxable base and tax amount per rate category. During extraction, an Inferred Column classifies each line item by rate based on the item description — food and beverage items at 8%, standard goods and services at 10%, explicitly exempt items as tax-exempt. The output spreadsheet groups items by tax rate, and the rate-grouped totals can be verified against the invoice's stated tax breakdown. If the two do not match — if the extraction's computed 8% total differs from the invoice's stated 8% total — the discrepancy is flagged for review, which is the same check the AP team would perform manually, but performed automatically on sixty invoices simultaneously.

From Sixty PDFs to One Payment-Ready Spreadsheet

The Japanese invoice is not simply a bill. It is a payment instruction — the bank details tell the AP team where to send the money. It is a tax document — the consumption tax breakdown feeds the national tax return, and the Qualified Invoice registration number is the prerequisite for input tax credit. It is a compliance record — the withholding tax classification triggers a separate tax deposit obligation on the buyer's side. And it is a matching artifact — the invoice number, line items, and amounts must be verified against the corresponding purchase order and delivery note before payment can be approved.

An extraction workflow that captures all of these fields — not just the total and the date — turns the month-end invoice stack from a data entry queue into a verification checklist. The bank transfer details are in columns, ready to become a payment batch file. The consumption tax is split by rate, ready to feed the tax return. The withholding classification is flagged, so no qualifying invoice is paid at full gross amount by mistake. The payment terms are parsed into settlement day and lag, so the payment calendar populates automatically. The spreadsheet arrives structured, and the AP team's time shifts from typing to verifying — from data entry to financial control.