EU SaaS in Japan: GDPR/APPI, Stripe and PAY.JP, JCT Qualified Invoices, and a Pricing Stack That Japanese Buyers Recognise

European SaaS founders who try to enter Japan tend to ask about the wrong things first. The early questions are usually about GDPR overlap, sometimes about translation, and almost always about whether a Japanese subsidiary is needed. The questions that matter most for revenue, by contrast, are mundane. How are Japanese customers actually going to pay. What does the invoice look like. Which security certification do procurement teams expect. Where does the pricing page need to be different from the European one. Those four questions decide whether the product gets bought, and they are the ones that get postponed until after the legal review, which is the wrong order.

This guide takes the operational stack from the buyer's perspective. It covers the GDPR-to-APPI alignment as a procurement concern rather than a treatise. It walks through Stripe, PAY.JP, and Komoju as the three viable payment configurations European SaaS uses in Japan, and where each one fits. It explains the JCT qualified invoice system and why it shows up as a deal-blocker for non-resident suppliers above the JPY 10 million threshold. It covers JPY pricing tier design, because the import of an unchanged European pricing page is one of the most consistent reasons European SaaS underperforms in Japan. And it explains why ISMS, not SOC 2, is the security signal that procurement teams want to see.

The guide is written for founders, CMOs, and country managers who are running an EU SaaS into Japan, not for legal teams. The legal questions are real and are flagged where they matter, but the centre of gravity is operational. Patric Sawada and Silkdrive deliver the broader entry context as part of the EU-Japan Centre cross-cultural growth marketing webinar programme; the wider commercial frame lives in the Japan Market Entry Guide, the SME-specific framework in Japan Market Entry for European SMEs, and the EPA-derived margin question in The EU-Japan EPA for Marketers.

The Personal Data Question: GDPR to APPI

Personal data flow is the question European SaaS asks first and answers worst. The standard worry is that APPI, the Japanese Act on the Protection of Personal Information, is a fundamentally different regime that requires a parallel compliance programme alongside GDPR. That picture was somewhat true a decade ago. After the 2017, 2020, and 2022 APPI amendments and the 2019 EU-Japan reciprocal adequacy decision, it is no longer the working reality.

The 2019 adequacy decision is the operational pivot. Adequacy decisions are formal Commission acts recognising that a non-EU jurisdiction provides a level of personal data protection essentially equivalent to the GDPR. When an adequacy decision is in place, EU controllers and processors can transfer personal data to that jurisdiction under the same conditions as a within-EU transfer. No standard contractual clauses, no binding corporate rules, no transfer impact assessment for the Japan leg. The Japan adequacy decision came into force on 23 January 2019 and was the first reciprocal adequacy arrangement the Commission concluded; the Japanese side recognises EU member states under symmetrical terms, which means Japanese controllers transferring to EU SaaS providers benefit from the same simplification.

The substantive APPI obligations have been progressively aligned with GDPR. The 2020 APPI amendment introduced data breach notification to the Personal Information Protection Commission and to data subjects, restricted retroactive consent withdrawals, and added pseudonymously processed information as a category. The 2022 amendment strengthened cross-border transfer disclosure and aligned several penalty provisions. The cumulative effect is that APPI in 2026 is GDPR-shaped on most of the items that matter for SaaS operators: lawful basis, transparency, subject rights, breach notification, third-party transfer disclosure, and accountability.

The practical compliance programme for EU SaaS therefore extends the existing GDPR programme rather than running in parallel. The delta work is concrete and small in scope. The privacy notice and consent flow needs Japanese-language equivalents that match APPI's specific disclosure requirements, including the third-party recipient and country-of-transfer disclosures that 2022 strengthened. The Data Processing Agreement template needs to acknowledge the EU-Japan adequacy decision and to capture the APPI breach notification standard. The data subject rights workflow needs to accept Japanese-language requests and to meet APPI's response timeframe expectations. The Article 30 record of processing activities, where one is maintained, needs an APPI section.

The PPC is the Japanese supervisory authority and the analogue of the European data protection authorities. Communication with the PPC is in Japanese, which is the most common operational gap; few European SaaS legal teams have Japanese-language regulatory communication capacity, and the gap usually surfaces during a customer's vendor security review when the customer asks how the SaaS would handle a PPC inquiry. The cleanest answer is to nominate a Japanese-speaking external advisor or counsel for PPC-facing communication and to document that nomination in the privacy notice.

The Article 27 GDPR concept of an EU representative does not have a direct APPI equivalent, but APPI does require non-resident operators handling personal information of Japanese residents to designate a representative in Japan. The 2020 amendment introduced this requirement, and most EU SaaS overlooks it during entry. The representative does not need to be a subsidiary; it can be a service provider that performs the same function as the GDPR Article 27 representative does for the Japanese regulator.

In every case where the European compliance programme is mature, the APPI extension can be done as a delta exercise in two to four weeks of focused legal time. Where the European programme is patchy, the APPI extension surfaces the underlying gaps and forces them to be fixed first.

Payments: Stripe, PAY.JP, and Komoju

The payment question is where the difference between a European and a Japanese SaaS operation becomes most concrete, and where the assumption that "we already use Stripe" produces the most consistent revenue underperformance.

Stripe is fully operational in Japan. Stripe Japan supports JPY billing, Japanese-language receipts, and a meaningful part of the Japanese payment method universe. On the cards side, Stripe accepts JCB alongside Visa, Mastercard, and Amex, which matters because JCB has approximately 28% domestic card market share among Japanese consumers. Stripe also supports Konbini cash payment, Pay-easy bank transfer, and JP Bank Transfer for Japanese customers, with pricing and reconciliation that work for B2B subscription scenarios. For cross-border B2B SaaS where the customer is a Japanese subsidiary of a European or American company that pays by corporate credit card, Stripe alone is sufficient.

The limit shows up in B2C and SMB Japan. Japanese consumers continue to prefer payment methods that European stacks rarely include by default. PayPay, the dominant Japanese mobile wallet, has more than 60 million users and is now the default consumer payment method for many transactions. Konbini payment, where the customer pays in cash or by mobile at a Lawson, FamilyMart, or 7-Eleven, remains substantial particularly for one-time purchases and for customers without credit cards. Direct debit (Kouza Furikae) and bank transfer (Furikomi) are standard for SMB B2B, where the procurement department typically does not pay subscriptions by corporate credit card and instead expects an invoice paid by transfer. LINE Pay and Rakuten Pay carry meaningful share. d-payment carries some.

PAY.JP, owned by GMO Internet Group, is the most common European-style alternative when broader Japanese coverage is needed. PAY.JP is a Japanese-domiciled processor with native support for the local methods plus credit cards, with a developer experience close enough to Stripe's that European engineering teams can work with it. PAY.JP's commercial terms differ from Stripe; the integration is a project rather than a one-day swap. The reasons to choose PAY.JP are usually local-method depth and a Japanese counterparty for the Japanese accounting team to deal with rather than a Stripe Inc. counterparty for support and billing.

Komoju, owned by Degica, is the third common option and is positioned slightly differently. Komoju focuses on aggregating local payment methods through one integration: konbini, PayPay, LINE Pay, bank transfer, and others, with cards as a secondary feature. Komoju's natural fit is European SaaS that wants the broadest local-method coverage and treats card payment as already solved by Stripe. The two-processor configuration of Stripe for cards and Komoju for local methods is common in cross-border SaaS that has scaled past the cross-border-only stage.

The decision matrix is concrete. A cross-border B2B SaaS with corporate-card-paying customers can run on Stripe alone. A B2C or SMB-heavy SaaS with substantial Japan revenue should add or switch to PAY.JP or Komoju, with the choice between them turning on whether the engineering team prefers a Japanese Stripe-equivalent (PAY.JP) or a local-method specialist (Komoju). An enterprise B2B SaaS will end up with at least Stripe plus invoice-and-transfer billing for the enterprise tier, and may add PAY.JP for the prosumer end of the price book. The two-processor configuration is more common than not.

JCT and the Qualified Invoice System

The Japanese Consumption Tax is the Japanese equivalent of VAT. The standard rate is 10% with a reduced 8% rate for food, beverages, and a few other categories. JCT applies to most goods and services consumed in Japan, including digital services supplied from outside Japan to Japanese customers. The 2015 reform extended JCT collection obligations to non-resident digital service providers selling B2C in Japan; the 2023 Inboisu reform extended that further into the B2B input-tax credit chain.

The Inboisu (qualified invoice) system entered force on 1 October 2023. Under the new system, Japanese businesses can claim input-tax credit on JCT they have paid only when their supplier is registered as a Qualified Invoice Issuer and the invoice carries the issuer's registration number, the applicable JCT rate, and the JCT amount. Suppliers that are not registered cannot issue qualified invoices; their customers therefore cannot claim the JCT they paid as input-tax credit, which makes the supplier effectively 10% more expensive on a like-for-like basis.

For European SaaS the practical implication is simple. Below the JPY 10 million threshold of taxable supply, the supplier is not required to register and many small operators choose not to. Above the threshold, registration is the default; not registering loses customers. Where the European SaaS sells through an entity outside Japan, the registration is for the Qualified Invoice Issuer status of that non-resident entity for its Japanese supply. The National Tax Agency operates the registration process and publishes the registry of Qualified Invoice Issuers, which Japanese customers commonly check before purchasing.

There is a transition arrangement for the period running through 2029 that allows partial input-tax credit on invoices from non-registered suppliers, on a tapering schedule. The transition reduces the immediate cost differential but does not eliminate it; by 2029 the differential is close to the full JCT rate. European SaaS should not rely on the transition as a long-term strategy.

The invoicing implementation is non-trivial. The qualified invoice has prescribed content beyond what most European invoicing systems produce by default: the issuer's qualified invoice registration number, the JCT applicable rate breakdown, the JCT amount per rate, and the customer's name. Japanese customers also expect tax-inclusive total display alongside tax-exclusive subtotal display. SaaS billing systems that produce a standard global invoice often need a Japan-specific invoice template and a registration-number field in the customer-facing payment receipt. Stripe Japan and PAY.JP both support qualified-invoice emission with the appropriate configuration; Komoju's invoicing layer is lighter and is often paired with a separate accounting tool for the qualified invoice.

The Inboisu obligation is independent of the data-protection and adequacy questions covered above. It can apply to a SaaS that has no personal data flow to manage and that does not need an EU-Japan adequacy template. Conversely, an SaaS that handles substantial personal data and gets the GDPR-to-APPI extension right can still lose customers because its non-qualified invoice makes it 10% more expensive in a procurement comparison.

JPY Pricing: Four to Five Tiers, Named the Way Japanese Buyers Expect

European SaaS pricing pages imported unchanged into Japan are a common cause of underperformance, and the cause is not currency conversion. JPY pricing is the easy part. The harder part is the tier structure. Japanese B2B and consumer buyers expect a recognisable shape, and pricing that does not match the shape reads as missing options or as too cheap to be enterprise-credible.

The working range is four to five tiers, each named in a way that maps to a Japanese buyer mental model. The most common pattern in successful Japanese SaaS is a tier sequence of free or trial entry, Light, Standard, Pro, and Enterprise. The Light tier is sized for a small team with a low-friction monthly price; in JPY that is typically in the JPY 1,500 to JPY 3,000 per user per month range for general productivity SaaS. The Standard tier is the default purchase point; in JPY it sits at JPY 3,000 to JPY 6,000 per user per month, which corresponds to the European EUR 20 to EUR 40 per user per month range with Japan-specific calibration. The Pro tier introduces advanced features and integration depth; JPY 6,000 to JPY 12,000 per user per month is the typical band. The Enterprise tier is annual-contracted, custom-invoiced, JCT-qualified, and ISMS-evidenced; the price is on a contact-sales basis.

The two-tier or three-tier pricing common in European SaaS reads as incomplete in Japan. A buyer evaluating a category will scan multiple options and compare tier shape; an option with only a Standard and a Pro tier will lose to an option with the recognisable five. The naming matters too; Light is more legible than "Starter" or "Basic" in Japanese B2B, and Pro is more legible than "Plus" or "Advanced." Calque names rarely translate well; the working approach is to use Japanese tier names that map to the buyer mental model rather than to translate the European tier names.

Annual versus monthly billing follows a similar local pattern. Japanese B2B prefers annual contracts with quarterly or monthly invoicing under the qualified invoice regime. The European pattern of monthly month-to-month subscription with credit-card auto-renew is less natural for the enterprise tier and produces friction at procurement. The standard configuration is monthly billing for Light and Standard, with Pro and Enterprise offered as annual contracts with optional monthly invoicing.

The pricing page itself benefits from Japan-specific design. The JCT-inclusive total is expected alongside the JCT-exclusive subtotal. The qualified invoice registration number should be displayed, often in the footer. ISMS certification and any ISO 27001 evidence should be visible at a glance, ideally with the certificate number and expiry date. A Japanese-language pricing page with a Japanese phone number and a Japanese contact form converts substantially better than a translated European pricing page with a +44 or +31 phone number and an English contact form. The conversion difference is often two to four times.

Security Signal: ISMS, Not SOC 2

Security certification is the deal-blocker that European SaaS notices last. The product is built, the privacy notice is up, the payment stack works, the invoicing is correct, and the deal stalls in procurement because the customer's vendor onboarding form asks for the ISMS certificate and the supplier offers SOC 2 instead. The two are not interchangeable in Japanese B2B procurement.

ISMS is the operational name of the ISO/IEC 27001 information security management system standard as implemented in Japan through the ISMS Conformity Assessment Scheme operated by JIPDEC. Japanese B2B procurement scoring sheets read ISMS as a baseline expectation. Vendor onboarding templates list ISMS as a default requirement. Risk assessments map their controls to the ISMS framework. The Japanese IT procurement universe is shaped around ISMS the way North American procurement is shaped around SOC 2.

SOC 2 is the AICPA Trust Services standard widely used in North American B2B. It is well-known among technology-forward Japanese buyers, particularly internet-native firms, but it is not the default in mainstream Japanese procurement. A Japanese procurement team that is not familiar with SOC 2 will not be able to map the SOC 2 report's assertions to its internal risk register without help, and the help typically does not exist on the procurement side. The conversation that opens automatically when ISMS is presented becomes a conversation that does not open when only SOC 2 is presented.

The cleanest approach for European SaaS entering Japan with non-trivial enterprise ambition is to plan for ISMS certification, in addition to whatever European or North American certifications already exist. Pre-certification ISMS readiness work runs four to six months for a SaaS with mature engineering practices and an existing ISO 27001-aligned control environment, with the certification body's audit cycle adding two to three months. The cost is meaningful but the procurement-cycle return is also meaningful; the absence of an ISMS certificate is a hard gate in many Japanese enterprise procurement workflows.

For SaaS entering with B2C or SMB focus the ISMS gate is softer, but the security trust signals on the pricing and product pages still matter. The cleanest configuration there is to align internally with ISO 27001 controls, to display the alignment on the security page, and to plan the formal certification for the second year of operation. The phased approach matches the natural sales-cycle ramp.

Three Entry Patterns

The combination of personal data, payments, JCT, pricing, and security simplifies into three entry patterns that capture most of the actual decisions European SaaS makes.

The first pattern is cross-border-only. The European SaaS sells from its existing EU entity. Stripe handles payment, JCT registration is taken or not depending on the threshold, the qualified invoice is emitted from the EU entity, the privacy notice is extended for APPI, no Japanese subsidiary is set up. ISMS is not pursued in year one. The pattern is viable for cross-border B2B with corporate-card-paying customers, for product-led B2B with English-comfortable users, and for the early phase of any entry where the volume is too small to justify deeper investment. The ceiling is around mid-six-figure annual JPY revenue and around enterprise procurement complexity; above either, the pattern starts to lose deals it should win.

The second pattern is partner or platform reseller. The European SaaS sells through a Japanese partner who handles the Japanese-language sales motion, JCT and qualified invoicing, customer support, and often the payment relationship. The partner is typically a system integrator (NTT Data, Fujitsu, NEC, Hitachi at the largest end), a category-specific Japanese SaaS distributor, or a marketplace such as Microsoft Japan's commercial marketplace or AWS Marketplace's Japan localised storefront. The pattern is viable when the European SaaS does not have the internal capacity for a Japanese sales motion and where the partner has the customer base. The trade-off is margin and the customer relationship; the partner controls both. ISMS and APPI sit on the partner's side rather than the European SaaS side, which simplifies year one and complicates year three when the partner economics change.

The third pattern is in-country: a Japanese subsidiary, KK or GK, with JCT registration, ISMS certification, native vendor management, and a Japanese-language commercial team. The pattern is the highest cost and the highest control. It is the right pattern for SaaS with serious enterprise B2B ambition and is the only pattern that supports the full Japanese procurement experience that enterprise customers expect. The lead time from decision to operational country team is six to twelve months, the year-one cost is substantial, and the three-year payback profile is steep but real if the underlying product fits.

The right pattern is the one that fits the revenue size, customer profile, and three-year cost tolerance. The wrong pattern is the one chosen by personal preference rather than by these three variables. The most common error is a cross-border-only entry pursued past its natural ceiling, where the operator continues to capture small deals while losing the large ones to competitors who set up properly in country. The second-most-common error is an in-country entry pursued before the European business is ready to fund a six-to-twelve-month country setup at the appropriate level. Both errors are recoverable but expensive.

A 12-Month Rollout for European SaaS

The sequence below is the one that has worked in practice for European SaaS entering Japan with at least nine months of runway before first material revenue.

Months one through three are preparation and decision. The entry pattern decision is locked. The personal-data delta to APPI is scoped and assigned. The JCT threshold and qualified-invoice plan is decided, with the timing of registration tied to the projected revenue ramp. The payment-stack decision is scoped: Stripe-only, Stripe-plus-Komoju, PAY.JP-replace, or PAY.JP-plus-Stripe. The pricing-page Japan version is drafted with the four-to-five-tier shape. The ISMS readiness path is decided in line with the entry pattern.

Months four through six are build. The Japanese privacy notice and consent flow ship. The DPA template is updated for adequacy. The Article 30 record gets its APPI section. The payment integrations ship and pass internal QA on a Japanese test environment. The JCT-qualified invoice template is implemented, with the registration-number field wired through the customer-facing receipt. The Japanese pricing page goes live with JPY pricing, the four-to-five-tier shape, and JCT-inclusive total display. The ISMS readiness work is in progress.

Months seven through nine are commercial launch. First deals close on the new stack. The qualified invoice cycle is exercised in production. The PPC representative arrangement is in place. The security-page display is updated to reflect ISMS readiness or certification status. The first cohort of Japanese customers provides feedback on the pricing-page tier shape, on the payment-method coverage, and on the security signals; the feedback feeds into a first round of post-launch refinement.

Months ten through twelve are first review. Customer churn and conversion data is sliced by tier and by payment method to validate or correct the tier and stack decisions. JCT registration status is reviewed against actual revenue. ISMS certification, where pursued, completes the audit cycle. The entry pattern decision is re-reviewed against twelve-month performance; the most useful question is whether the original pattern is still the right one given the actual customer mix.

The discipline of the rollout is more important than the precise sequencing. The principle is that the four operational questions (data, payments, invoicing, security) interact and have to be solved together rather than as separate tracks. Treating them as separate is the most common failure mode and produces the kind of half-localised launch that Japanese buyers correctly read as not yet ready.

The Wider Entry Context

The compliance and operational stack does not solve the commercial problem on its own. Japanese SaaS buyers buy on trust, on referenceability, on local presence, and on cultural calibration of the sales motion. The compliance stack is necessary, the operational stack is necessary, and the commercial work on top of both is what produces revenue.

The wider entry frame is in Japan Market Entry Guide, which covers entry models, B2C and B2B channel logic, and the cross-cultural marketing layer. The SME-specific framework is in Japan Market Entry for European SMEs. The EPA-derived margin question that funds much of the operational work is in The EU-Japan EPA for Marketers. The budget context is in The Real Cost of Entering the Japanese Market. The Netherlands-Japan corridor specifics are in The Netherlands-Japan Business Corridor. The cultural-marketing layer is in the Cross-Cultural Marketing Guide. The cultural foundation is in Japanese Business Culture: A Working Guide. For SaaS entering Japan as part of a broader Asia or global expansion, the International Business Expansion Guide sets the cross-market context.

The European SaaS that gets the most from Japan is the one that treats the four operational questions as primary rather than as cleanup work after a strategic decision. The compliance and operational stack is the strategic decision, in practice. The rest is sales execution.

Sources

• Personal Information Protection Commission of Japan, the regulator implementing APPI and the Japanese half of the reciprocal adequacy decision.
• European Commission, Adequacy decisions, official list including the Japan reciprocal adequacy decision in force since January 2019.
• Stripe Japan, product pages with Japan-specific payment methods, pricing, and integration documentation.
• National Tax Agency, Japan, the JCT and qualified invoice system regulator with English-language guidance on the Inboisu regime.
• JIPDEC ISMS Conformity Assessment Scheme, the Japanese implementation of ISO/IEC 27001 with certified-organisation registry.
• JETRO, Japan External Trade Organization with cross-border SaaS guidance and invest-in-Japan support.
• EU-Japan Centre for Industrial Cooperation, the official EU-Japan bilateral support institution with programmes for European SaaS founders.

---

Patric Sawada is an EU-Japan Centre accredited expert and the founder of Silkdrive. Married into a Japanese family and based in Amsterdam, he has spent 11+ years in cross-cultural growth marketing across Europe and East/Southeast Asia, working with 50+ companies across 30 industries. Silkdrive delivers cross-cultural growth marketing for European SMEs entering Japan.