Finance teams invoicing in Türkiye rarely fail at accounting — they fail at the handoff. Business Central posts a sales invoice cleanly, and then someone re-keys it into a portal or an integrator's web screen, checks by hand whether the buyer is registered on the GİB e-Fatura user list, picks a scenario, and hopes the tax lines survive the trip. Out of the box, Business Central has no concept of an e-Fatura scenario, no Vergi Kimlik No / TCKN validation on the customer card, no UBL-TR envelope, and no place to store the GİB reference, the ETTN, or a rejection reason against the posted document. The localization gap is not the invoice — it is everything that has to happen in the ninety seconds after posting.

What we build is a per-tenant AL extension (or an AppSource-shaped app where you prefer that packaging) that closes that gap inside Business Central. A table extension on Customer carries the tax identifier, the GİB alias (PK/GB labels), the registered-user flag and the last user-list check timestamp; a page extension surfaces them on the Customer Card with validation that rejects a 10-digit VKN in a TCKN field before anyone posts anything. On posting we subscribe to OnAfterPostSalesDoc in Codeunit 80 Sales-Post, resolve the scenario — e-Fatura for a registered buyer, e-Arşiv for everyone else, including the retail and internet-sales variants — and write an outbound document record. A dedicated codeunit builds the UBL-TR payload from Business Central master data: tax identifiers, VAT Posting Setup mapped to Turkish tax type codes, withholding and exemption codes where the setup calls for them, line-level discounts, and currency handling for foreign-currency invoices. The same posting run produces the human-readable copy from a report object, so the machine format and the printed PDF can never drift apart.

Transmission runs through your chosen GİB-authorized integrator (Özel Entegratör). We implement the connector against their API, keep credentials in Isolated Storage rather than a setup field anyone can read, and drive submission and status polling from Job Queue entries so nothing depends on a user having the client open. Every state change — queued, sent, accepted, rejected, cancelled — lands on the outbound record with the integrator's response and the GİB identifiers, visible from the posted invoice through a factbox and a Document Status page. Rejections are the part most implementations skip: you get a correction workflow that reads the rejection reason, blocks silent re-sends of the same document, and drives the corrective flow the scenario requires, so nobody fixes a rejected invoice in a spreadsheet.

Archiving and evidence are first-class. The transmitted payload, the signed response and the rendered copy are retained against the document with an append-only status history, so an audit question is answered from Business Central rather than from an integrator's portal export. We ship dedicated permission sets — an accountant who issues invoices does not need the setup rights that hold integrator credentials — and expose document state through API pages (REST API v2.0 / OData v4) so a Power Automate flow, a Dataverse-connected app or a Power BI compliance dashboard can read status without anyone building a second integration.

Delivery is build-to-order: this is not an AppSource download you install today. You request a quotation, we run a scoping call on your Business Central version and topology (SaaS online or on-premises), your integrator, your VAT and withholding setup and your document layouts. We then build against your environment, deploy to a sandbox for UAT with your own customers and tax codes, and go live with a rollback plan. Typical delivery is two to four weeks from confirmed scope, and the source code, the git repository and the technical documentation are handed over so the extension remains yours to maintain or extend.