How to Convert Japanese Delivery Notes to Excel

If you need to convert Japanese delivery notes to Excel, the first thing to get right is the document's role. A Japanese delivery note, or 納品書, is a receiving document rather than the invoice itself, so teams usually extract it before AP processing starts. The spreadsheet typically needs item lines, quantities, delivery dates, supplier details, PO references, and optional price fields, because some Japanese delivery notes include pricing and others do not.

The 納品書 confirms what was delivered, when it arrived, and which items or quantities need to be checked. The later 請求書 is the billing document used for payment approval and coding. When those two are treated as interchangeable, the same items end up logged twice — once as delivered, once as billed — and quantity discrepancies surface only at month-end.

Build an Excel schema that works for priced and non-priced 納品書

The spreadsheet has to reflect how Japanese delivery notes are actually used, not just what text happens to appear on the page. In practice, the core columns are usually:

• Delivery note number
• Supplier name
• Delivery date
• PO or order reference
• Item name
• Quantity
• Unit
• Spec, size, or pack detail
• Unit price, if present
• Total amount, if present
• Notes or discrepancy flag
• Source file and page

OIST's supplier guidance for business partners in Japan confirms that delivery slips can carry both document-level and line-level information, including the price fields above, which are real fields on Japanese delivery notes rather than invoice-only concepts.

Line-item output is usually more useful than one row per document. One line per item lets the spreadsheet preserve quantities, pack sizes, and product descriptions in a way receiving teams can review directly; document-level fields such as supplier name, delivery note number, and delivery date simply repeat on each row. Source file and page on every row make the sheet trustworthy: when a quantity looks wrong, AP can jump back to the exact page instead of searching through a stack of Japanese PDFs by hand.

The Japanese document details that trip up generic OCR

Japanese delivery notes carry several conventions that generic OCR pipelines were not built for, and each one quietly shifts cleanup work into the spreadsheet stage:

• Tategaki (vertical text). Some supplier templates run header labels or product descriptions top-to-bottom along the right margin. Generic pipelines either skip the vertical block or fold its characters into the wrong row, breaking reading order before field mapping starts.
• Japanese era dates. Issue and delivery dates appear as 令和7年4月1日 or 平成31年, sometimes mixed with Gregorian dates on the same document. Without era-to-Gregorian normalization, the spreadsheet ends up with strings the rest of AP cannot filter or sort.
• Full-width digits and punctuation. Quantities, prices, and PO references can arrive as １２３ rather than 123. Until they are normalized to half-width, downstream sums, lookups, and matching fail silently.
• Supplier names with 株式会社 and branch labels. The legal entity prefix or suffix (株式会社) and branch markers (支店, 営業所) attach without a clean separator. Canonicalizing the supplier string is what makes vendor matching against AP master data possible at all.

For spreadsheet work, the real problem is field mapping rather than raw character capture. If a product spec slides into the item-name column or a PO reference is mistaken for the delivery note number, the row looks complete while still being wrong enough to break receiving checks. The same date-normalization and full-width-digit handling matters whenever you convert Japanese bank statements to Excel or any other Japanese supplier document.

Prompt the extraction around rows, dates, and page traceability

Once the schema is clear, the prompt should describe the spreadsheet rather than ask for text extraction. Five concrete levers do most of the work: produce one row per line item; repeat document-level fields (delivery note number, supplier, delivery date) on every row; normalize dates to YYYY-MM-DD, converting era dates such as 令和7年4月1日 to Gregorian; leave optional price cells blank when the 納品書 carries no pricing rather than forcing zeros; and include the source file and page number on every row so reviewers can verify ambiguous items quickly. Telling the system to ignore non-operational marks (stamps, handwritten checks, cover pages) keeps the output tidier still.

Invoice Data Extraction is built around this kind of prompt-led control, so Japanese delivery notes from different supplier layouts can land in a consistent Excel schema without templates or per-supplier rules.

Use the spreadsheet for receiving checks, discrepancy review, and invoice matching

Once the data is in Excel, the delivery note stops being a static attachment and becomes a working control record. Receiving teams can confirm delivered quantities against what was expected, flag shortages or over-deliveries, and keep a clean audit record — even when the 納品書 carries no prices, because the row still records item lines, quantities, dates, and PO references while commercial values arrive later on the 請求書. For a clearer explanation of when Japanese businesses keep both documents, it helps to look at the receiving record and the billing record side by side.

From there, the rows can support discrepancy review and later reconciliation. If a supplier invoice shows a different quantity, product description, or reference number, the team can match delivery notes against supplier invoices without rebuilding the receiving history from scratch. When the billing stage begins, it also helps to read Japanese invoices and map the key fields against the delivery data that already exists. Supermarket and food-wholesale accounting teams handling high-volume month-end closes can extend the same approach to 納品書・納品明細書をExcelに一括取り込みして三点突合と仕入計上を効率化する手順, including CSV連携 with マネーフォワード, freee, 弥生, and 勘定奉行.

In practice, this is where the broader value of invoice and financial document extraction becomes clear. Delivery notes, invoices, and related supplier documents are easier to control when each document type is extracted into structured data at the stage where it is actually used, rather than being treated as one undifferentiated stack of PDFs.

When a workflow-built extractor beats manual copy-paste or basic OCR

Manual entry handles a small trickle when layouts are stable, and raw OCR is enough when the only goal is searchable text. A workflow-built extractor starts to justify itself once Japanese delivery notes vary by supplier, optional pricing has to be preserved without guessed values, line items need to stay intact across rows, and source-page traceability is required for every entry. If the same approach has to scale beyond Japan-specific documents, the playbook for converting generic delivery note PDFs to Excel covers the cross-format baseline.