Why 確定申告 Data Assembly Costs
Japanese Freelancers More Than They Realize

The Four Physical Streams That Feed Into a Digital Return

A freelancer filing 確定申告 does not start with a blank form and fill it from memory. The Form B (B様式) has over 40 fields distributed across Sheet 1 (第一表), Sheet 2 (第二表), and the income statement (収支内訳書 or 青色申告決算書). Every one of those fields requires a number, and the numbers live in four separate physical or semi-physical sources — none of which talk to each other.

The assembly problem is not that any single stream is impossibly hard. It is that none of them converge automatically. The freelancer is the integration layer — the human middleware between four document stacks and a 40-field tax form. Every February, 4 million people perform this integration manually. And the integration layer is where errors multiply.

The Form Itself: Why 40+ Fields Across Multiple Sheets Makes Manual Entry Error-Prone

Form B is not a simple income-minus-expenses calculation. It is a seven-block computational structure with intermediate subtotals, cross-sheet references, and fields that auto-populate from earlier sections. A freelancer transcribing numbers from the four physical streams into the form — whether on paper, through the NTA Preparation Corner, or in accounting software — must navigate a layout that was designed for computational completeness, not for data entry efficiency.

The deduction block alone illustrates the problem. Social insurance (社会保険料控除) is line 21. Small business mutual aid (小規模企業共済等掛金控除) is line 22. Life insurance (生命保険料控除) is line 24. Earthquake insurance (地震保険料控除) is line 25. Medical expenses (医療費控除) is line 27. Each line has a specific row number, and the row numbers do not change — but the printed value is different for every filer, and the source certificate for each deduction arrives in a separate envelope. A freelancer transcribing five deduction amounts from five certificates into five form lines has five opportunities to transpose a number, skip a line, or enter a payment amount (支払金額) where a deduction amount (控除額) belongs — two different numbers from the same certificate, with different tax consequences.

The Aoiro Shinkoku Complication: Double-Entry Bookkeeping on Top of Everything Else

Freelancers filing under the blue return system (青色申告, aoiro shinkoku) — the option chosen by most self-employed filers because it unlocks the ¥650,000 special deduction under the Special Taxation Measures Act Article 25-2 (租税特別措置法第25条の2) — face an additional layer of complexity. Blue return filing requires double-entry bookkeeping (複式簿記): every transaction must be recorded as both a debit and a credit in the general ledger (総勘定元帳), and the resulting trial balance (合計残高試算表) must reconcile to zero before the Blue Return Financial Statement (青色申告決算書) can be generated.

The financial statement itself has three components that white return filers never touch: a balance sheet (貸借対照表) listing assets, liabilities, and net worth; a profit-and-loss statement (損益計算書) breaking down revenue and expenses by category; and a detailed expense schedule showing monthly totals for each expense category. A freelancer whose bookkeeping has been cash-basis all year — recording income when it arrives and expenses when they're paid — must convert to accrual-basis at year-end for the balance sheet. This is not a data entry problem. It is an accounting methodology problem layered on top of the data assembly problem, and it arrives in the same four-week window as everything else.

The Structural Gap: e-Tax Is Digital Output, but the Input Is Still Physical

Japan's tax administration has invested heavily in digital filing infrastructure. The e-Tax system, operated by the National Tax Agency (国税庁, NTA), accepts electronic submissions of individual income tax returns with My Number card authentication. The NTA's Preparation Corner provides a web-based form builder that guides filers through each section. Accounting software — freee, Yayoi, MoneyForward — generates the return as a finished PDF or e-Tax XML package ready for one-click submission. From the NTA's perspective, the filing pipeline is digital end-to-end.

From the freelancer's perspective, only the last mile is digital. The data that fills the form — the income totals, the expense amounts, the deduction figures — still originates from physical documents that must be located, read, transcribed, and verified before the digital form can be populated. The freelancer who opens the NTA Preparation Corner on February 20 and arrives at the "Business Income (事業所得, 収入金額)" field still needs to walk to the desk drawer, open the bank passbook (通帳), tally 12 months of business deposits by hand, and type the result. The form builder cannot read the passbook. The accounting software cannot read the passbook unless the freelancer has been manually entering transactions all year. The digital filing pipeline is a highway — but the on-ramp is a staircase.

This is the structural gap that the term "確定申告 automation" obscures. Automating the form-filling and the submission is a solved problem. Automating the data assembly — the four-week upstream phase where numbers migrate from paper to screen — is not. And the gap is invisible in the marketing language of "AI-powered tax filing" because the NTA, the software vendors, and the tax accountant industry all measure automation from the point where the data is already digital.

The same structural gap exists in other areas of Japanese small business finance. The paper passbook (通帳) manual data entry problem — where small business owners hand-copy transaction data from a passbook into accounting software — is the same phenomenon: a digital destination that demands a manual journey. And it is not unique to Japan. A UK freelancer facing the SA100 Self Assessment paper problem experiences the same structural gap — HMRC's online filing system is digital end-to-end, but the P60, bank statements, and expense receipts that feed into the SA100 are still paper.

The Compounding Cost: Why Each Error Creates More Work, Not Less

Manual transcription errors in 確定申告 do not fail independently. They compound — an error in one field cascades into errors in derived fields, and correcting the cascade requires retracing every step from the error point forward.

Consider the sequence. A freelancer transcribes business income from the passbook as ¥4,200,000 — but the correct figure, after excluding a ¥300,000 personal transfer, is ¥3,900,000. The ¥300,000 overstatement survives all the way to taxable income. The tax calculation on that inflated base produces a higher tax liability. The prepaid tax from last year — already calculated and paid — now looks insufficient against the inflated liability, making it appear the freelancer owes additional tax. The freelancer pays the inflated amount. The following year, the NTA's prepaid tax calculation — based on the inflated liability — demands higher advance payments. One transcription error in February 2025 cascades into an overpayment in March 2025, an inflated prepaid demand in July 2025, and a corrective filing requirement when the discrepancy is eventually discovered.

The irony is that the freelancer is not incompetent. They are performing a task — matching values from four different physical document stacks to 40-plus form fields across three sheets — that exceeds the reliable accuracy of human visual transcription. Research on manual data entry accuracy in financial contexts consistently finds error rates of 1–3% per field under normal working conditions. At 40 fields per return, a 1% per-field error rate produces a 33% probability that at least one field contains an error. For 4 million filers, that is over 1.3 million returns with at least one transcription mistake — and each mistake triggers the compounding correction cycle described above.

What Changes When the Assembly Phase Becomes Automated

The solution is not a better form. It is removing the human transcription step from the assembly pipeline entirely. Instead of the freelancer reading numbers from four document stacks and typing them into a form, the freelancer scans or photographs the source documents — the passbook pages, the receipts, the insurance certificates, the previous year's return — and uploads them into a single batch. An extraction tool that reads Form B (B様式) fields by their semantic meaning — "this value is the Medical Expense Deduction, regardless of which line it appears on" — pulls every field from every document and assembles the return in a spreadsheet, one row per tax year, every field in its column.

The freelancer's role shifts from transcriber to verifier. Instead of spending two hours typing numbers from paper to screen — and another hour double-checking for transcription errors — the freelancer spends 15 minutes scanning, receives a completed spreadsheet, and reviews the output. A Computed Column that cross-checks the sum of individual deduction fields against the printed total on Sheet 1 catches the most common error class — deduction arithmetic mismatches — automatically. The freelancer reviews the flagged rows, not every row. The time recovered shifts from keystrokes to verification — and verification is a task the human brain is better at than the AI, while transcription is a task the AI is better at than the human.

For freelancers who work with a tax accountant (税理士), the same extraction pipeline benefits both sides. Instead of handing the accountant a stack of documents that they retype into their own analysis spreadsheet — a process that takes the accountant roughly two hours per client return — the freelancer provides an extracted spreadsheet with every field already in columns. The accountant opens the file, imports it into their tax software — Yayoi Tax, TKC, or MJS via CSV import — and begins the review immediately. The two hours the accountant would have spent retyping becomes two hours of tax strategy discussion. At the accountant's fee of ¥110,000–¥165,000 per return, that shift in how the time is spent is the difference between paying for data entry and paying for professional judgment.

Frequently Asked Questions

The Real Cost Is Not the Hours. It Is the February That Could Have Been.

The time cost of manual 確定申告 assembly is quantifiable: roughly two to three full working days spread across the four-week window between mid-February and mid-March, per freelancer, per year. Multiply by 4 million filers and the aggregate is staggering. But the real cost is not the hours spent typing numbers. It is what those hours displace: the client work that could have been done, the tax planning that could have been performed, the evening that could have been spent not reconciling a passbook against a spreadsheet.

The 確定申告 is a statutory obligation — the deadline does not move, and the consequences of late filing (5–20% penalty on tax owed, plus delinquency interest) are substantial. But the assembly phase that precedes filing is not statutory. It is an artifact of a system where the filing endpoint is digital but the data sources are not. Closing that gap — replacing the human transcription step with extraction that reads documents by semantic meaning — does not eliminate the obligation. It eliminates the part of the obligation that nobody pays you for, and that nobody designed the system around: the four weeks you spend being the integration layer between paper and pixels.