CODE IN TOKYO

Technical Pitfalls When Launching a SaaS in Japan

You have a SaaS that works. Bringing it to Japan looks like translation and localization, and not much else.

It rarely goes that way. What stops the launch is usually technical, and usually sits deep in the design.

Here are the issues worth settling before you commit to a Japan launch.

Names and addresses break the data model first

This is what you hit earliest.

A Japanese name does not fit in one string field.

It needs a phonetic reading — furigana in kana. Payments, delivery, financial identity verification, and most Japanese business systems assume they can match on it. Adding the field later means deciding what to do about every existing user.

The character range is also wider than you expect. Full-width alphanumerics. Half-width katakana. And variant characters — the specific glyph in a surname like Takashima or Yamazaki is not always the common one.

Do you normalize these, or store them as entered? Decide before implementation. Skip it and it resurfaces as searches that do not match and documents that render as garbage.

Check the database encoding too. Storing emoji and some kanji in MySQL requires utf8mb4; on plain utf8 the write fails.

Addresses have the same problem. Prefecture, municipality, block number, building name. Poured into a Western address schema, the block number has nowhere to go.

And the block number is a string, not an integer. It may be “1-2-3” or it may be written out in kanji.

Phone numbers and email start from not being delivered

If you store phone numbers in E.164, decide how you handle the leading zero.

Japanese numbers start with 0. Converting to international format drops it. Forget to restore it on display and the user does not recognize their own number.

Area codes are not a fixed length either. Validation that assumes one will reject valid numbers.

Email is worse.

Japanese carrier mail domains — docomo, au, softbank — often have domain-level receive filtering configured by the user. Your mail does not arrive, and no error comes back to you.

SPF, DKIM, and DMARC are the floor. Beyond that, you need a path that lets a user recover on their own when mail does not reach them.

Credit cards alone will not close the sale

For a Japanese consumer service, card-only means leaving revenue on the table.

How far you go depends on the target, but card-only is not a workable assumption.

Business customers are a different problem entirely.

Japanese B2B runs on invoiced payment. Terms like “closed at month end, paid at the end of the following month” are the norm.

That means extending credit, selling on account, issuing an invoice, and reconciling the payment against it. That whole flow has to exist in the product.

A subscription billing system built around card-on-file is missing all of it.

Invoices require a registration number

Japan’s qualified invoice system took effect in 2023.

A compliant invoice must carry the issuer’s registration number, the applicable tax rates, and the consumption tax amount broken out per rate.

Consumption tax is 10 percent, but food and some other items fall under a reduced 8 percent rate. Confirm your design assumes two rates can coexist on one invoice.

If you generate invoice PDFs, the template usually does not meet these requirements out of the box.

Documents may need Japanese era years and a April fiscal year

For enterprise and public-sector customers, generated documents may need dates in the Japanese era calendar — Reiwa 7, for example.

Era changes happen, so keep the conversion table in configuration rather than in code.

Then there is the fiscal year. Japan’s runs April through March. If your aggregation and closing periods are hard-wired to the calendar year, they cannot be used as-is.

You will be asked where the data lives

This is less a technical requirement than something that surfaces in contract review.

Latency first. Whether to run in the Tokyo region is not only a speed question.

Japanese companies — larger enterprises and the public sector especially — ask where data is stored on their security review questionnaires. A deployment that exists only in overseas regions slows that review down by itself.

Look at the personal information protection law as well. Transferring personal data outside Japan generally requires the individual’s consent or an equivalent safeguard. That shapes your privacy policy and consent flow.

Electronic record retention rules may also apply. If you handle invoices or receipts electronically, confirm you meet the storage requirements.

The legal judgment belongs to specialists. Knowing which of these issues rebound onto your technical design does not.

How I would approach it

There is an order to this.

Start with the data model. Names, addresses, phone numbers, dates. Read the code and confirm those four can absorb Japanese requirements.

If they cannot, everything else you build is rework. If they can, the rest is usually additive.

Payments and invoicing come second. If you are selling to businesses, supporting invoiced payment is effectively the price of entry.

Data residency and legal come last among the blockers — but settle them before sales starts moving, because that is where contract review stalls.

Translation and UI localization can wait. It is the visible part, so it is tempting to do first. What stops launches is never the visible part.