SAP Business One in Türkiye: e-Fatura, e-Arşiv, e-Defter

SAP Business One runs in Türkiye on an official SAP localization, and Türkiye is one of the 13 countries my SAP B1 clients come from. The question I get from Turkish finance teams is rarely about the general ledger. It is about the four GİB e-document systems, e-Fatura, e-Arşiv Fatura, e-İrsaliye and e-Defter, and how much of that SAP Business One does on its own. This page gives the honest answer: what SAP’s Turkey localization covers, what it does not, the current thresholds and dates from VUK Genel Tebliği 509 and the Elektronik Defter Genel Tebliği as the GİB publishes them, and a SQL query that catches broken VKN and TCKN numbers in your business partner master data before an e-Fatura is rejected for them.

I am Zain Abbas, a SAP Business One developer with more than 7 years of SAP B1 work for companies in 13 countries. My e-invoicing integrations are for Saudi Arabia, Ecuador, Guatemala, El Salvador and Panama, all clearance-model countries where every invoice is signed in a UBL or JSON schema and reported to the tax authority. Türkiye’s e-Fatura is the same model with a Turkish UBL profile, so most of what follows about data quality and master data comes from those projects. The Turkish rules come from SAP’s documentation and the GİB’s own texts, linked at the end.

What does the Turkey localization of SAP Business One cover?

You pick Turkey as the localization when the company database is created, and SAP does not let you change it afterwards. SAP’s Localization for Turkey help for release 10.0 indexes 96 topics. Grouped, they cover:

What is not in that list matters more. There is no e-Fatura, e-Arşiv, e-İrsaliye or e-Defter topic anywhere in the Turkey localization documentation, and no Electronic Document Service protocol for Türkiye like the ones SAP ships for Spain or Italy. I checked on 10 November 2026. In practice a Turkish SAP Business One company runs a partner add-on that reads A/R invoices, credit memos and deliveries, builds the UBL-TR XML, and hands it to a GİB-licensed özel entegratör, or files the e-Defter XBRL from the journal. When you evaluate a Turkish partner, ask which add-on they use and who the entegratör is; SAP itself is not on the GİB’s list of licensed özel entegratör companies, which runs to more than 90 names.

One setup detail that bites: SAP Knowledge Base Article 3729497 says that account segmentation cannot be enabled when the company was created with the predefined CATR chart of accounts, SAP’s template for the Turkish uniform chart of accounts (Tekdüzen Hesap Planı). If you need segmented accounts, decide before you create the database.

Which GİB e-document rules apply to a Turkish company?

Türkiye does not have one e-invoicing mandate. It has four related systems under VUK Genel Tebliği 509, consolidated by the GİB and last amended by Tebliğ 589 of 31 December 2025, plus the e-Defter regulation. This is the state on 10 November 2026:

Three details change how you plan a SAP project:

• The thresholds are gross sales, not profit. Section IV.1.4 uses brüt satış hasılatı (or sales plus gross business revenue). A trading company with thin margins crosses 3 million TL long before it feels big, and once in, it stays in.
• e-Fatura and e-Defter arrive together. Section 3.2.1 of the e-Defter Tebliğ makes every e-Fatura obligee an e-Defter obligee, and section 3.2.6 sets the same deadline. A SAP Business One project that plans e-Fatura for July and e-Defter “later” is already late.
• Berat deadlines are monthly unless you opt out. Section 4.3.4: journal and ledger files for a month, with their berat, must be created, signed and uploaded by the end of the 10th day of the fourth month after it for income tax payers, and the 14th day for other taxpayers. The year’s last month follows the tax return: the 10th or 14th day of the month after the return is filed. Companies can switch to quarterly uploads aligned with the advance tax (geçici vergi) periods, but only by electing it in the first month of the fiscal year, and the election then binds every later year. Each month counts separately for penalties.

The GİB can also impose any of the four systems on a taxpayer it rates as risky or low-compliance, regardless of sector or revenue, with a written notice and at least three months to prepare. Treat the thresholds as the floor, not the whole rule.

What do you connect SAP Business One to for e-Fatura?

The GİB’s own page lists three ways to use e-Fatura: the GİB portal, a direct integration of your own system with the GİB, and an özel entegratör. For SAP Business One the choice is almost always the third, because the entegratör holds the Mali Mühür signing and archiving obligations and gives you a REST or SOAP endpoint. The partner add-on then has four jobs, and this is where projects go right or wrong:

1. Buyer classification. Before every invoice, the add-on must know whether the customer’s VKN or TCKN is in the GİB registered-user list, and which alias (etiket) it uses. Registered buyer means e-Fatura, otherwise e-Arşiv. Most entegratör APIs expose a lookup; the add-on should store the result on the business partner, not look it up at print time only.
2. Document mapping. OINV and INV1 to UBL-TR 1.2.1 (the current GİB guide): invoice type codes (SATIS, IADE, TEVKIFAT, ISTISNA, IHRACKAYITLI), tax codes with the GİB numeric codes (0015 for KDV), tevkifat withholding codes and rates, exemption reason codes, unit codes, currency and exchange rate for export invoices. In SAP Business One these live in the tax group, withholding tax code and unit of measure masters, so most of the mapping is configuration, not code.
3. Status and retries. Every document gets a GİB status (sent, accepted, rejected, cancelled) that must flow back into SAP Business One, preferably on user-defined fields on the invoice so that Crystal layouts and queries can see it.
4. Inbound. Incoming e-Fatura and e-İrsaliye arrive at your alias and should become draft A/P invoices or goods receipts, matched by VKN to the vendor.

What carries over from my clearance-model projects:

• Keep SAP Business One as the only numbering source. An e-Fatura number is a 3-letter prefix, the year and a 9-digit sequence, and the GİB sees gaps. The add-on should take the number from a dedicated SAP Business One document series and never generate its own, or you will spend the first month-end reconciling two lists.
• Walk the tax code mapping with the accountant before anyone writes XML. Tevkifat on SAP Business One is a withholding tax code with a rate; in UBL-TR it is a withholding code, a rate and an invoice type. Istisna is a tax group with 0% in SAP and an exemption reason code in the XML. If those two views are not written down side by side and signed off, the rejections start on day one.
• Clean master data before the pilot, not after. An e-Fatura addressed to a wrong VKN is delivered to the wrong taxpayer or nobody, and a TCKN with a bad check digit fails the schema check at the entegratör. The query below finds those before go-live.

How do you find Turkish customers with an invalid VKN or TCKN?

A VKN (vergi kimlik numarası) is 10 digits with a check digit computed by the GİB algorithm: for each of the first nine digits, add its position weight (9 down to 1), take the result modulo 10, multiply by 2 raised to the same weight, take modulo 9, and treat a zero as 9 unless the first step was already zero; the check digit is 10 minus the sum modulo 10. A TCKN (T.C. kimlik numarası) is 11 digits, never starting with 0, where the tenth digit is (7 times the sum of digits 1, 3, 5, 7, 9 minus the sum of digits 2, 4, 6, 8) modulo 10 and the eleventh is the sum of the first ten modulo 10. SAP Business One keeps the number in OCRD.LicTradNum, often with a TR prefix, spaces or dots.

This query checks every active Turkish customer and reports what is wrong:

-- SQL Server: Turkish customers with a missing or invalid VKN / TCKN
WITH BP AS (
    SELECT CardCode, CardName,
           REPLACE(REPLACE(REPLACE(ISNULL(LicTradNum, ''), ' ', ''), '.', ''), '-', '') AS Raw
    FROM OCRD
    WHERE CardType = 'C' AND Country = 'TR' AND frozenFor = 'N'
), N AS (
    SELECT CardCode, CardName,
           CASE WHEN LEFT(Raw, 2) = 'TR' THEN SUBSTRING(Raw, 3, 20) ELSE Raw END AS TaxNo
    FROM BP
), V AS (
    -- VKN check digit: sum over positions 1..9
    SELECT N.CardCode,
           (10 - SUM(CASE WHEN T.t <> 0 AND (T.t * POWER(2, 10 - P.i)) % 9 = 0 THEN 9
                          ELSE (T.t * POWER(2, 10 - P.i)) % 9 END) % 10) % 10 AS Chk
    FROM N
    CROSS APPLY (VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9)) AS P(i)
    CROSS APPLY (SELECT (CAST(SUBSTRING(N.TaxNo, P.i, 1) AS INT) + (10 - P.i)) % 10 AS t) AS T
    WHERE N.TaxNo LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
    GROUP BY N.CardCode
), T AS (
    -- TCKN check digits
    SELECT CardCode,
           (((7 * (D1 + D3 + D5 + D7 + D9) - (D2 + D4 + D6 + D8)) % 10) + 10) % 10 AS C10,
           (D1 + D2 + D3 + D4 + D5 + D6 + D7 + D8 + D9 + D10) % 10 AS C11
    FROM (
        SELECT CardCode,
               CAST(SUBSTRING(TaxNo, 1, 1) AS INT) D1, CAST(SUBSTRING(TaxNo, 2, 1) AS INT) D2,
               CAST(SUBSTRING(TaxNo, 3, 1) AS INT) D3, CAST(SUBSTRING(TaxNo, 4, 1) AS INT) D4,
               CAST(SUBSTRING(TaxNo, 5, 1) AS INT) D5, CAST(SUBSTRING(TaxNo, 6, 1) AS INT) D6,
               CAST(SUBSTRING(TaxNo, 7, 1) AS INT) D7, CAST(SUBSTRING(TaxNo, 8, 1) AS INT) D8,
               CAST(SUBSTRING(TaxNo, 9, 1) AS INT) D9, CAST(SUBSTRING(TaxNo, 10, 1) AS INT) D10
        FROM N
        WHERE TaxNo LIKE '[1-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
    ) X
)
SELECT N.CardCode, N.CardName, N.TaxNo,
       CASE
           WHEN N.TaxNo = '' THEN 'Missing tax ID'
           WHEN LEN(N.TaxNo) = 10 AND V.Chk IS NULL THEN 'VKN has non-digits'
           WHEN LEN(N.TaxNo) = 10 AND V.Chk <> CAST(RIGHT(N.TaxNo, 1) AS INT) THEN 'VKN check digit wrong'
           WHEN LEN(N.TaxNo) = 10 THEN 'OK (VKN)'
           WHEN LEN(N.TaxNo) = 11 AND T.C10 IS NULL THEN 'TCKN has non-digits or starts with 0'
           WHEN LEN(N.TaxNo) = 11 AND (T.C10 <> CAST(SUBSTRING(N.TaxNo, 10, 1) AS INT)
                                    OR T.C11 <> CAST(SUBSTRING(N.TaxNo, 11, 1) AS INT)) THEN 'TCKN check digits wrong'
           WHEN LEN(N.TaxNo) = 11 THEN 'OK (TCKN)'
           ELSE 'Wrong length'
       END AS Problem
FROM N
LEFT JOIN V ON V.CardCode = N.CardCode
LEFT JOIN T ON T.CardCode = N.CardCode
WHERE N.TaxNo = '' OR LEN(N.TaxNo) NOT IN (10, 11)
   OR (LEN(N.TaxNo) = 10 AND (V.Chk IS NULL OR V.Chk <> CAST(RIGHT(N.TaxNo, 1) AS INT)))
   OR (LEN(N.TaxNo) = 11 AND (T.C10 IS NULL OR T.C10 <> CAST(SUBSTRING(N.TaxNo, 10, 1) AS INT)
                                            OR T.C11 <> CAST(SUBSTRING(N.TaxNo, 11, 1) AS INT)))
ORDER BY Problem, N.CardCode

-- SAP HANA version
WITH BP AS (
    SELECT "CardCode", "CardName",
           REPLACE(REPLACE(REPLACE(IFNULL("LicTradNum", ''), ' ', ''), '.', ''), '-', '') AS "Raw"
    FROM OCRD
    WHERE "CardType" = 'C' AND "Country" = 'TR' AND "frozenFor" = 'N'
), N AS (
    SELECT "CardCode", "CardName",
           CASE WHEN LEFT("Raw", 2) = 'TR' THEN SUBSTRING("Raw", 3, 20) ELSE "Raw" END AS "TaxNo"
    FROM BP
), P AS (
    SELECT 1 AS "i" FROM DUMMY UNION ALL SELECT 2 FROM DUMMY UNION ALL SELECT 3 FROM DUMMY
    UNION ALL SELECT 4 FROM DUMMY UNION ALL SELECT 5 FROM DUMMY UNION ALL SELECT 6 FROM DUMMY
    UNION ALL SELECT 7 FROM DUMMY UNION ALL SELECT 8 FROM DUMMY UNION ALL SELECT 9 FROM DUMMY
), V AS (
    SELECT "CardCode",
           MOD(10 - MOD(SUM(CASE WHEN "t" <> 0 AND MOD("t" * POWER(2, 10 - "i"), 9) = 0 THEN 9
                                 ELSE MOD("t" * POWER(2, 10 - "i"), 9) END), 10), 10) AS "Chk"
    FROM (
        SELECT N."CardCode", P."i",
               MOD(TO_INTEGER(SUBSTRING(N."TaxNo", P."i", 1)) + (10 - P."i"), 10) AS "t"
        FROM N CROSS JOIN P
        WHERE N."TaxNo" LIKE_REGEXPR '^[0-9]{10}$'
    ) S
    GROUP BY "CardCode"
), T AS (
    SELECT "CardCode",
           MOD(MOD(7 * ("D1" + "D3" + "D5" + "D7" + "D9") - ("D2" + "D4" + "D6" + "D8"), 10) + 10, 10) AS "C10",
           MOD("D1" + "D2" + "D3" + "D4" + "D5" + "D6" + "D7" + "D8" + "D9" + "D10", 10) AS "C11"
    FROM (
        SELECT "CardCode",
               TO_INTEGER(SUBSTRING("TaxNo", 1, 1)) "D1", TO_INTEGER(SUBSTRING("TaxNo", 2, 1)) "D2",
               TO_INTEGER(SUBSTRING("TaxNo", 3, 1)) "D3", TO_INTEGER(SUBSTRING("TaxNo", 4, 1)) "D4",
               TO_INTEGER(SUBSTRING("TaxNo", 5, 1)) "D5", TO_INTEGER(SUBSTRING("TaxNo", 6, 1)) "D6",
               TO_INTEGER(SUBSTRING("TaxNo", 7, 1)) "D7", TO_INTEGER(SUBSTRING("TaxNo", 8, 1)) "D8",
               TO_INTEGER(SUBSTRING("TaxNo", 9, 1)) "D9", TO_INTEGER(SUBSTRING("TaxNo", 10, 1)) "D10"
        FROM N
        WHERE "TaxNo" LIKE_REGEXPR '^[1-9][0-9]{10}$'
    ) X
)
SELECT N."CardCode", N."CardName", N."TaxNo",
       CASE
           WHEN N."TaxNo" = '' THEN 'Missing tax ID'
           WHEN LENGTH(N."TaxNo") = 10 AND V."Chk" IS NULL THEN 'VKN has non-digits'
           WHEN LENGTH(N."TaxNo") = 10 AND V."Chk" <> TO_INTEGER(RIGHT(N."TaxNo", 1)) THEN 'VKN check digit wrong'
           WHEN LENGTH(N."TaxNo") = 10 THEN 'OK (VKN)'
           WHEN LENGTH(N."TaxNo") = 11 AND T."C10" IS NULL THEN 'TCKN has non-digits or starts with 0'
           WHEN LENGTH(N."TaxNo") = 11 AND (T."C10" <> TO_INTEGER(SUBSTRING(N."TaxNo", 10, 1))
                                         OR T."C11" <> TO_INTEGER(SUBSTRING(N."TaxNo", 11, 1))) THEN 'TCKN check digits wrong'
           WHEN LENGTH(N."TaxNo") = 11 THEN 'OK (TCKN)'
           ELSE 'Wrong length'
       END AS "Problem"
FROM N
LEFT JOIN V ON V."CardCode" = N."CardCode"
LEFT JOIN T ON T."CardCode" = N."CardCode"
WHERE N."TaxNo" = '' OR LENGTH(N."TaxNo") NOT IN (10, 11)
   OR (LENGTH(N."TaxNo") = 10 AND (V."Chk" IS NULL OR V."Chk" <> TO_INTEGER(RIGHT(N."TaxNo", 1))))
   OR (LENGTH(N."TaxNo") = 11 AND (T."C10" IS NULL OR T."C10" <> TO_INTEGER(SUBSTRING(N."TaxNo", 10, 1))
                                                 OR T."C11" <> TO_INTEGER(SUBSTRING(N."TaxNo", 11, 1))))
ORDER BY "Problem", N."CardCode"

Notes from running checks like this:

• I tested the logic, not your data. The two algorithms return valid for the GİB’s published test identity number 10000000146 and for VKNs generated with the official check-digit rule, and they catch a one-digit change in either. Run the query on a test copy first and read the “Wrong length” rows by hand: foreign customers created with Country = TR, and old records with the tax office name typed into the tax ID field, land there.
• Vendors too. Change CardType to ‘S’. Inbound e-Fatura is matched to your vendors by VKN, and the e-Defter journal carries business partner tax numbers, so a bad vendor VKN shows up in both.
• Tax office is a separate field. The UBL-TR invoice needs the buyer’s vergi dairesi for a VKN customer, and the standard business partner master has no field for it in SAP Business One. Add a user-defined field on OCRD and make the e-Fatura add-on read it; do not stuff it into the tax ID.
• Then block new ones. Add the same check to SBO_SP_TransactionNotification for object 2 (business partners), so a Turkish customer cannot be saved with a broken VKN or TCKN. The TransactionNotification examples show the pattern.

The OCRD page lists the business partner fields, and the SQL to HANA converter rewrites other queries between the two dialects.

Which ERP systems are common in Türkiye?

Small and mid-sized Turkish companies very often run domestic software from Logo, Mikro, Netsis (now part of Logo) or Uyumsoft, which ship e-Fatura and e-Defter built in and are themselves licensed özel entegratör companies. Companies that belong to an international group, export heavily or report to a foreign parent more often run SAP Business One, Microsoft Dynamics 365 Business Central or SAP S/4HANA, and connect to the GİB through an add-on or a connector from one of the entegratör companies. The GİB rules apply to all of them equally, so the question for a buyer is less which ERP and more who signs, archives and files for you, and what happens to your archive if you change vendor. The ERP Selector compares systems by country requirement.

What can Kodenova do for SAP Business One users in Türkiye?

I work remotely from Pakistan, 2 hours ahead of Türkiye, so the Turkish working day from 09:00 to 18:00 is 11:00 to 20:00 for me and meetings fit without anyone working at night. What I do:

• Master data clean-up before e-Fatura: VKN and TCKN, tax office, tax groups and withholding codes, with queries like the one above and a list of what to fix.
• Validation rules in SBO_SP_TransactionNotification: block a Turkish customer with an invalid tax number, or an A/R invoice that is missing the fields your add-on needs for the UBL-TR mapping.
• Integrations through the Service Layer: web shops, marketplaces, banks and the status fields your e-Fatura add-on writes back, so reports and dashboards show GİB status next to the invoice. See the Service Layer guide.
• Add-ons, queries, reports and SQL Server to HANA migration. See the add-on development guide and the migration guide.
• AI on top of SAP B1: an MCP server so ChatGPT or Claude can answer from live SAP data, with permissions.

To be clear about scope: the e-invoicing integrations I have built are for Saudi Arabia, Ecuador, Guatemala, El Salvador and Panama. For Türkiye I do not sell an e-Fatura, e-Arşiv or e-Defter product and I am not an özel entegratör; those documents go through a GİB-licensed entegratör and the add-on your partner provides, and I work on the SAP side around it. I do not give tax advice. Kodenova is not an SAP partner and does not resell licences; if you have a partner for licences and support, I work alongside them on development. Other country pages: Saudi Arabia, Spain, Germany and the full list on the SAP Business One hub.

Sources

• SAP Help Portal: Localization for Turkey (SAP Business One 10.0)
• SAP Help Portal: Setup and Administration: Turkey
• SAP Help Portal: Tax Reports: Turkey
• SAP Help Portal: Document Journal Report and General Ledger Report (Turkey)
• SAP Help Portal: Year End Closing: Turkey
• SAP Help Portal: Folio Number Assignment
• SAP Knowledge Base Article 3729497: Account Segmentation with the predefined CATR chart of accounts (Turkey)
• GİB e-Belge: Vergi Usul Kanunu Genel Tebliği (Sıra No: 509), consolidated text with footnotes (PDF)
• GİB e-Belge: Tebliğ (Sıra No: 589) amending Tebliğ 509, Resmî Gazete 31 December 2025 (PDF)
• GİB e-Belge: e-Fatura Uygulamasından Yararlanma Yöntemleri (portal, integration, özel entegratör)
• GİB e-Belge: list of licensed özel entegratör companies
• GİB e-Belge: e-Fatura legislation and UBL-TR guides
• GİB e-Defter: Elektronik Defter Genel Tebliği (Sıra No: 1), consolidated text (PDF)
• GİB e-Defter: e-Defter Hakkında

Related services

• SAP Business One development
• E-invoicing integration