How JP freelance devs invoice USD clients without losing ¥50k/month to FX and 適格請求書 errors (2026)

You just wrapped a three-month contract for a US startup. They paid $12,000 via Wise. Your Japanese accountant asks for the 適格請求書 (qualified invoice). You open the PDF you sent the client — it's in English, dollars only, no 登録番号, no 消費税 breakdown. You stare at it and realize you have to recreate six invoices retroactively, convert every line to JPY at the correct TTM rate for the issue date, and somehow make it all comply with the invoice system that started October 2023.

This is the quiet tax on being a Japanese freelance developer with overseas clients. Nobody tells you about it at the tech meetups. You find out in March when your 税理士 sends a polite email titled 「ご確認のお願い」.

I've been freelancing from Tokyo for six years, invoicing clients in USD, EUR, and JPY. The first year I lost roughly ¥600,000 in unclaimed 消費税 credits, FX slippage, and one client who refused to pay because my invoice format didn't match their AP system. This article is the system I wish I'd had on day one.

The real cost of getting JP freelance invoicing wrong

Let me put numbers on it, because "be careful with invoices" is useless advice.

Here's what actually bleeds money for a freelance dev billing ¥8M/year with a mix of JP and overseas clients:

Mistake	Typical annual cost
Missing 登録番号 on invoices to JP clients	¥200,000-¥400,000 (clients deduct 消費税 from your next invoice)
Wrong FX rate on USD→JPY conversion for tax reporting	¥50,000-¥150,000 (over-reported income)
No 消費税 line on JP client invoices	¥80,000 per ¥1M invoice (client refuses to pay it separately)
Late payment because invoice format rejected by client AP	30-60 day cashflow delay, sometimes write-offs
Recreating invoices for 税務調査	20-40 hours of your time

The 適格請求書等保存方式 (invoice system) went live October 1, 2023. If you're not 登録事業者, your JP clients can't claim the consumption tax you charge them, and they will quietly route work to competitors who are registered. If you are registered but your invoice is missing required fields, the client can legally refuse the 消費税 portion.

Meanwhile your overseas clients don't care about any of this — they want a clean PDF in USD with their PO number on it. So you need two invoice formats. Or rather, one invoice that speaks both languages.

What a 適格請求書 actually requires in 2026

Let's strip the bureaucracy. The National Tax Agency requires these six items on every qualified invoice:

1. 適格請求書発行事業者の氏名又は名称 and 登録番号 (starts with T followed by 13 digits)
2. 取引年月日 (transaction date)
3. 取引内容 — and if it includes 軽減税率 items, mark them clearly
4. 税率ごとに区分して合計した対価の額 (subtotal per tax rate, tax-exclusive or inclusive)
5. 税率ごとの消費税額 (consumption tax amount per rate)
6. 書類の交付を受ける事業者の氏名又は名称 (client name)

For software dev work you'll almost always be at 標準税率 10%. 軽減税率 8% applies to food/drink and some newspapers — not your React work.

Here's the minimum-viable qualified invoice structure as pseudo-schema:

Invoice {
  issuer: {
    name: "山田太郎",
    registration_no: "T1234567890123",  // required
    address: "東京都渋谷区...",
    bank: { name, branch, account_type, number, holder_kana }
  },
  client: { name: "株式会社サンプル 御中" },
  invoice_no: "2026-001",
  issue_date: "2026-03-31",
  line_items: [
    { desc: "フロントエンド開発 (2026年3月分)", qty: 1, unit_price: 800000, tax_rate: 0.10 }
  ],
  subtotal_by_rate: { "10%": 800000 },
  tax_by_rate:      { "10%":  80000 },
  total: 880000,
  payment_due: "2026-04-30",
  notes: "振込手数料は貴社ご負担でお願いいたします"
}

Miss the 登録番号 and it's not a qualified invoice. Miss the per-rate subtotal and it's not a qualified invoice. The form matters.

The dual-currency problem nobody warns you about

Here's the scenario that broke me in year one.

Alex, a PM at a Seattle-based SaaS company, emails: "Can you invoice us $9,500 for March? Net 30, wire to your Japanese bank."

Fine. You send a PDF: INVOICE #2026-004 — $9,500.00 USD. They pay. Wise deposits ¥1,423,182 on April 15th.

Now 確定申告 season arrives. Your accountant asks: "この売上、いつの為替レートで計上しましたか?"

Correct answer per NTA rules: you should book the revenue at the TTM rate on the invoice issue date (or delivery date — there are a few acceptable methods, but you must pick one and be consistent). Not the date you got paid. Not the Wise rate. The published TTM from a major Japanese bank on the issue date.

So for an invoice issued March 31, you look up MUFG's 3/31 TTM — let's say ¥149.80 — and book ¥1,423,100 as revenue. The ¥82 difference vs what actually hit your account becomes 為替差損益, reported separately.

If you only stored the USD amount on the invoice, you're now reconstructing exchange rates months later for every single invoice. I did this my first year. It took a weekend.

The fix: put both currencies on the invoice at issue time. Lock the rate in writing.

Subtotal:          USD 9,500.00   (JPY 1,423,100)
JCT (N/A - export):    USD 0.00   (JPY         0)
Total:             USD 9,500.00   (JPY 1,423,100)

FX rate locked at issue date (2026-03-31): 1 USD = 149.80 JPY
Source: MUFG TTM

Two benefits: your accountant has everything they need on one document, and if the client disputes the JPY conversion later (rare but happens), you have a documented source.

For cross-border B2B software services to a non-resident company, 消費税 is usually 0% (輸出免税) — but you still need to document it as such, and keep proof the client is non-resident. A note like JCT: Exempt (export of services under Article 7 of the Consumption Tax Act) on the invoice saves arguments later.

A checklist I run through before sending any invoice

I taped this to the side of my monitor for a year. Still use it mentally today.

• [ ] Invoice number follows a sequence (no gaps, no duplicates — NTA hates gaps)
• [ ] Issue date is correct and matches the period the work was delivered in
• [ ] My 登録番号 (T + 13 digits) is present and correct
• [ ] My legal name matches exactly what's registered with NTA
• [ ] Client name includes 御中 (for companies) or 様 (for individuals)
• [ ] Line items describe the work specifically (not just "consulting")
• [ ] Tax rate is shown per line AND subtotaled per rate
• [ ] 消費税額 is calculated with consistent rounding (round per rate, not per line — this changed in 2023)
• [ ] For overseas clients: both currencies shown, FX rate + source noted
• [ ] For overseas clients: 輸出免税 note included if applicable
• [ ] Bank details in 半角 numbers, account holder in カタカナ
• [ ] Payment terms explicit (Net 30, etc.) with due date calculated
• [ ] 振込手数料 responsibility stated
• [ ] PDF filename follows a pattern (INV-2026-004_ClientName.pdf)
• [ ] Saved to archive folder before sending

That last one saved me during a 税務調査 preliminary inquiry. Every invoice, in order, in a folder, named consistently. The inspector asked for three specific invoices; I had them in ten seconds. The meeting was short.

Building it in Excel (and why I stopped using online invoice SaaS)

I tried Freee, MakeLeaps, Misoca, and two US-based invoicing SaaS products. They all had one of these problems:

• Great at JP invoices, terrible at USD (or vice versa)
• Couldn't handle dual-currency display on one invoice
• Charged ¥1,000-¥3,000/month forever
• Lock-in: if you stop paying, your historical invoices become hard to export cleanly
• Couldn't customize the layout to match a specific client's AP requirements

Excel (or Numbers, or LibreOffice Calc) wins for freelance devs because:

• One file per invoice, archived forever, readable in 10 years
• Zero recurring cost
• Fully customizable — every client wants something slightly different
• Formulas handle tax math and FX conversion automatically
• Export to PDF is one click
• Your accountant can open it

The core formulas you need are simple. Here's the 消費税 calculation that's compliant with post-2023 rounding rules:

' Subtotal per rate (sum of line items at that rate)
B20 = SUMIF(D5:D15, 0.10, C5:C15)

' Tax per rate — round DOWN at the rate level, not per line
B21 = ROUNDDOWN(B20 * 0.10, 0)

' Grand total
B22 = B20 + B21

' Dual currency display
C20 = B20 / $FX_RATE   ' where $FX_RATE is the locked rate cell

The ROUNDDOWN at the rate subtotal level is the post-invoice-system standard. Rounding per line item is still allowed if you're consistent, but rate-level rounding is cleaner and matches most 税理士 software.

For the FX lookup, I keep a tiny reference sheet:

| Date       | USD/JPY TTM | Source |
|------------|-------------|--------|
| 2026-01-31 | 151.20      | MUFG   |
| 2026-02-28 | 150.45      | MUFG   |
| 2026-03-31 | 149.80      | MUFG   |

And a VLOOKUP pulls the right rate based on the invoice date. One source, consistent method, auditable.

The client-facing part nobody teaches devs

Technical compliance is half the job. The other half is how the invoice lands in the client's AP workflow. Here's what I learned the hard way:

Japanese client AP departments want: PDF attached to email, Subject line containing 【ご請求書】 and your company name, invoice filename in Japanese or ASCII (never mixed), and a polite 本文 that restates the invoice number, amount, and due date. They file emails by subject. If your subject is "March invoice", you become invisible.

Example email body that gets paid on time:

株式会社サンプル
経理ご担当者様

いつも大変お世話になっております。山田です。

2026年3月分のご請求書をお送りいたします。
ご査収のほどよろしくお願いいたします。

■請求書番号:2026-004
■請求金額:¥880,000(税込)
■お支払期限:2026年4月30日

何かご不明点がございましたらお気軽にご連絡ください。

山田 太郎

US/EU client AP departments want: invoice number in the email subject, PO number on the invoice if they gave you one, payment terms in plain English ("Net 30, due April 30, 2026"), and wire instructions formatted exactly how their bank expects. Include SWIFT/BIC, intermediary bank if needed, and IBAN-equivalent (for JP banks, the branch + account number works but label it clearly).

Mix these up and you get paid 30 days late. I once sent a US client an invoice with 【ご請求書】 in the subject. Their Outlook rendered it as mojibake and it went to spam. Learned that one on day 47 of waiting.

The part most freelancers skip: the archive

The NTA requires you to retain invoices (both issued and received) for seven years — ten years if you're carrying forward losses. Post-2024, electronic invoices sent/received electronically must be stored electronically with certain searchability requirements (電子帳簿保存法).

Minimum viable archive structure:

/invoices
  /2026
    /issued
      INV-2026-001_ClientA.pdf
      INV-2026-001_ClientA.xlsx
      INV-2026-002_ClientB.pdf
      ...
    /received
      2026-01-15_AWS_[vendor_reg_no].pdf
      2026-01-20_GitHub_[vendor_reg_no].pdf
      ...
  /_index.xlsx   ← searchable by date, amount, client

The _index.xlsx is the cheat code. Columns: 日付, 取引先, 金額(税抜), 消費税, 金額(税込), 登録番号, ファイル名, 支払状況. When your 税理士 asks for "that invoice from the Kyoto client in August", you filter and find it in five seconds.

For received invoices from vendors, check if their 登録番号 is present. If it's missing from a vendor you regularly use, ask them politely — if they're not registered, you can't claim the consumption tax on what they charge you, and you need to plan around it.

Putting it all together

Over six years this evolved into a system with specific pieces:

• 20 Excel templates covering the variations I actually hit: domestic JP only, JP + overseas mix, USD-primary, EUR-primary, monthly retainer, milestone-based, hourly, 源泉徴収対応, 軽減税率 mixed (rare for devs but happens if you bill meals back), and a few client-specific layouts that matched common JP enterprise AP formats
• Pre-built 適格請求書 fields with 登録番号 placeholder and per-rate subtotaling baked into formulas
• Dual-currency display with FX rate lookup from a reference sheet
• English + Japanese labels side-by-side so one template serves both client types
• The archive index spreadsheet
• A short PDF cheat sheet covering the checklist, the email templates, and the 確定申告 mapping (which cells feed which lines on 収支内訳書)

I systematized all of this into Dual-Currency Invoice Templates for JP Freelance Devs — 20 Excel templates, 適格請求書 ready, dual-currency built in, no subscription, works offline, yours forever. Every template I'm actually using in 2026 to invoice clients in Tokyo, San Francisco, and Berlin from the same laptop.

If you're a freelance dev in Japan billing any mix of domestic and overseas clients, this saves you the weekend I lost rebuilding six months of invoices, plus the ¥600k I lost in year one to FX mistakes and missing fields. At ¥3,000-ish it pays for itself on the first invoice that doesn't get rejected.

Get it here: Dual-Currency Invoice Templates on Gumroad →

---

Want the complete Dual-Currency Invoice Template pack I used? View on Gumroad →