After Nov 17, this Turkish accounting extension breaks along with the problem it solves

E-Defter Görüntüleyici is a free extension that helps Turkish accountants view electronic ledgers in Chrome. It has gathered 346 users in 5 months, and all 5 ratings are five stars. On the surface it looks like it caught the migration window from Chrome turning off XSLT. Looking inside the package, the reverse is true: it runs on XSLT itself, and will break when Chrome 158 ships on Nov 17. Below: how it gathered its small user base, where the migrating traffic went, and what's still left to build here.

"After the update, that option is gone"

On the morning of Dec 1, 2025, @Muhasebizm, a Turkish X user who calls themselves Mali Müşavir (certified public accountant), posted asking peers: "When you submit e-Defter, how do you view the XML? We used to open it in Microsoft Edge in Internet Explorer mode, and after an update that option is gone..." The post has 20k+ views, 90 likes and 52 bookmarks (X, 11-06). The replies offered ideas: someone posted Edge's IE mode allowlist settings, and someone else shared the customer support note from accounting software Luca: "After the Edge update, berat can no longer be opened directly. Please switch to Firefox."

e-Defter is the electronic ledger mandated by Turkey's tax office (GİB). In 2023, 695k taxpayers used it (TÜRKKEP citing GİB data), and in practice it's handled mostly by accounting firms. The ledgers are XML, and they only display in the "official format" with a GİB XSLT template. For years people kept the XML and template in the same folder and opened them in IE with a double-click. After IE was retired, Edge needs IE mode turned on, Firefox needs a security setting changed in about:config, and Chrome has always blocked local files from referencing external templates, so they won't open. GİB's own viewer is a Windows desktop program that requires Java, which accountants find heavy.

This small nuisance has been around for years, and E-Defter Görüntüleyici was built to solve it.

What it is

A Turkish-language Chrome extension. Drop Yevmiye (journal), Kebir (general ledger), Defter Raporu, and the matching berat receipt files (.xml or .zip) into the popup. It picks the GİB template from the filename markers -Y-, -K-, -DR-, -YB-, and -KB-, renders the ledger in a new tab, and lets you zoom, print, or save as PDF. The store page says "%100 güvenli" (100% secure) because everything runs locally and no files go to any server.

It's free, with no in-app purchases and no website. The author is Atilla Cem Gürgün, an independent developer in Istanbul; his LinkedIn says he has done on-site sales for Turkish accounting software vendor Zirve since 2003. The version number is still 1.0 as of today, and it hasn't been updated since it launched in Jun 8.

The key is that the templates are bundled inside the extension rather than looked up in a local folder, which gets around Chrome's block on local files. That still works today.

How the 346 users came in

Chrome Web Store, 11-01 to 11-06. About two new users a day, with no spikes.

Essentially there's one entry point: in Nov 6, searching "e-defter" in the Chrome Web Store returns only two results, and it ranks first; the other is QNB Bank's e-signature extension. The store also lists it as a "related extension" alongside E-Mükellef Toolbar (10k users, a companion toolbar for the e-Mükellef accounting software), which suggests the people arriving are indeed from the accounting-firm crowd. The author spent twenty years selling accounting software, so some users may come from his old client network (inferred). No one was found recommending it on websites, X or LinkedIn, and there's no content, no ads and no SEO.

So it hasn't really "taken off." It just holds a small keyword almost nobody searches for and nobody is fighting over.

What happens in Nov 17

Chrome 158 ships its stable release in Nov 17 2026, and from that version on, the browser's built-in XSLT is turned off for all users. Chrome's official notice is clear: what's disabled is not just the <?xml-stylesheet?> line in XML files, but also XSLTProcessor in JavaScript. Exemptions are only available to sites that enroll in the Origin Trial and to companies with an enterprise policy, and both of those end in Chrome 176 (2027 August).

For Turkish accountants, this means the last "just double-click and it works" route is closing. On the surface, this looks like a window for the e-Defter extension to pick up users.

The problem is that this extension is itself standing on the path that's closing. Lines 157 to 159 of popup.js in the package do new XSLTProcessor(), load the template and transform. The bundled documentation also says "the core of the extension is the browser's built-in XSLTProcessor API." The official docs grant no separate exemption for extensions, so after Nov 17 it will most likely fail to open ledgers (inferred, not tested on Chrome 158). If the author switches to a JavaScript or WASM XSLT engine before then, it can survive, but the extension hasn't been touched in five months, so we think that's unlikely.

The package has other traces too: a 881 KB SheetJS spreadsheet library is bundled, but Excel and Word export is still listed as "to do later"; there's a 0-byte html-to-docx.js and a draft file Untitled-1.txt; the documentation is titled "E-Belge Görüntüleyici", and the plan was apparently to cover e-Fatura and e-Arşiv too. It looks like a side project the author shipped before finishing.

Where the migrating traffic went

After Chrome turned off XSLT, pages like these show a banner, and clicking it leads to a store results page for "xslt polyfill". This traffic didn't go to the accounting extension. It went to generic extensions with polyfill in the name:

The most direct rival is DefterOku. Its author Barış Gerçek posted a launch on LinkedIn about a month ago, opening with "Since Nov 17, e-Defter berat may not open in Chrome anymore," then listing five points: no Java or any program to install; shows the official GİB format without browser XSLT; signature verification and İbraz checks; multi-page Excel and PDF; files never leave your computer, no sign-up. The last line: "If files from different accounting software break, tell me and I'll fix it fast." That's a whole lap ahead of E-Defter Görüntüleyici, and it's already on the new path.

At first glance the replacements all look like web tools that upload ledgers to a server, which accountants resist, so a local plugin seems like the differentiator. That's not quite right: solto and DefterOku both advertise local processing, and both prepared for the XSLT removal earlier than this one.

If it were you

C: worth studying, not worth copying. The plugin itself never took off (5 months, 346 users), and its technical base fails in 11 days. The migration traffic it was meant to catch is already being taken by general polyfill plugins and dedicated web tools like DefterOku. What's left is a gap for "a Turkish-accounting-specific plugin that doesn't depend on XSLT," but it's small, hard to monetize, and the competitors are free.

Who it suits: people who read Turkish, know GİB e-documents, or already build software or resell for Turkish accountants. For them it's a handy small tool and a way into accounting-firm clients. Who it doesn't suit: anyone hoping to make money from a single plugin. Accountants want to view ledgers for free; the official program, accounting software and several web tools are all free, and only a handful of people search e-defter in the store.

How to build it: don't use the browser's native XSLTProcessor; bundle the xslt-polyfill Chrome officially recommends, or parse the layout yourself. One plugin covers all three file types, e-Defter, e-Fatura and e-İrsaliye, brings DefterOku's web-based signature check, batch opening and Excel export into the plugin, and adds one thing the web can't do well: open a whole month of ledgers at once from the folder your accounting software exports to.

How to get users: put both "e-Defter" and "XSLT" in the name and description, capturing the unclaimed e-defter search in the store plus the traffic from Chrome's banner that leads to "xslt polyfill" search results. Then, in posts under @Muhasebizm, in the user groups for Luca and Mikro, and in accountants' LinkedIn circles, explain in Turkish what to use to open berat after Nov 17.

When to launch: ideally before Nov 17, when accountants will be searching for fixes. Missing it isn't fatal, since Chrome 176 (2027 August) removes the enterprise exemption and brings a second wave.

Signs you've misread it: ① the author ships a new version before Nov 17 that switches to polyfill, and users grow past a thousand by late November, showing accountants want a dedicated plugin and this gap is wider than thought; ② conversely, after Nov 17 its user count turns down and reviews mention "açılmıyor" (won't open), confirming the thesis above; ③ if GİB or a major accounting software vendor ships a built-in web viewer in November, this small gap closes.

Last line for anyone tracking "a platform is removing a feature": the window is real, but you have to grab the new path. First confirm your product doesn't rely on the thing that's about to disappear.

Data and sources

• Store page: chromewebstore.google.com/detail/dikbojdfoadmogopmoibdbdhgncadnal (11-06); user counts from 11-01 to 11-05 come from daily Chrome Web Store scrapes.
• Package: v1.0 CRX downloaded from Google's update server; unpacked and read popup.js and the bundled readme.
• XSLT removal: developer.chrome.com/docs/web-platform/deprecating-xslt.
• The accountant's question: x.com/Muhasebizm/status/1995418588271026531 (2025-12-01; views and likes as seen 11-06), plus the Luca support note quoted in the replies.
• DefterOku: defteroku.com, the author Barış Gerçek's LinkedIn launch post (read 11-06, showing "1 months ago").
• Other competitors: store pages for XSLT Polyfill and XSLT Browser Support; edefter.solto.net.
• e-Defter user count: TÜRKKEP citing GİB data (2023). Author background from a LinkedIn search snippet.