Turkish VAT Refund Errors in SAP: The 7 Most Common Mistakes and a Checklist

Short answer: The most common Turkish VAT refund errors come from data gathered from different sources not matching. A gap between the bill of materials and actual consumption, duplicate allocation, a period mismatch between the invoice and the customs export declaration (GÇB) and missing reconciliations are the reasons seen most often.

This article covers the seven errors we see most often in companies running SAP and how to prevent each one. At the end there is a 10-point checklist to use before submitting a refund file.

Why does a refund file come back with a deficiency notice?

When reviewing a refund claim, the tax office compares the lists, the VAT return and the accounting records. When it finds an inconsistency, it sends the company a deficiency notice (eksiklik yazısı), and the refund waits until the deficiency is resolved. Each notice can delay the refund by weeks; for export-heavy companies, that is a direct working capital cost.

The calculation of VAT borne (yüklenilen KDV) rests on a few clear rules: direct costs, the overhead share and the fixed asset share. We explain the method in detail in Turkish VAT refund calculation. Most deficiency notices arise while the method is applied, as data is brought together from different modules and periods. The seven errors below are the most common at that stage.

The 7 most common errors

1. Gap between the bill of materials and actual consumption

What happens: VAT borne is calculated with the quantities in the standard bill of materials (BOM). In production, actual consumption differed because of scrap, substitute materials or off-recipe consumption.

Why it is a problem: The refund calculation is based on the quantity that actually went into the product. A calculation based on the standard recipe shows a difference when compared with inventory records and triggers an inspection question.

How to prevent it: The calculation is built on actual consumption from production orders; the standard recipe is used only for comparison. Variances above a set threshold are reported and their justification is added to the file.

2. Duplicate allocation

What happens: The same quantity of the same purchase invoice enters the calculation of two different periods or two different refund types (for example, exports and reduced-rate sales).

Why it is a problem: The same VAT is claimed twice. This is among the most serious findings and can lead to recovery of the excess refund.

How to prevent it: The used and remaining quantity of each purchase invoice is kept permanently at invoice line level. Each new period’s calculation is built only on the remaining quantity.

3. Period mismatch between the invoice and the customs declaration

What happens: The export invoice is issued in one month and the customs export declaration (GÇB) falls into the next; or one invoice is partially closed by several declarations.

Why it is a problem: It becomes unclear in which period the refund right arose. An unmatched invoice or declaration separates the amounts on the lists from the VAT return.

How to prevent it: Each export invoice is matched, with the quantity closed, to one or more customs declarations. Open invoices and declarations are tracked on a separate list every period.

4. Not separating DİİB purchases

What happens: Raw materials bought without paying VAT under an Inward Processing Authorisation Certificate (DİİB) are held in stock together with VAT-paid purchases of the same material and are not separated in the calculation.

Why it is a problem: VAT that was never paid ends up in VAT borne. Purchases under the certificate are also examined when the certificate is closed.

How to prevent it: Purchases under and outside the certificate are tracked separately in inventory (for example, with a separate batch or stock type). The calculation uses this separation to determine which purchase went into the product.

5. Inconsistent allocation key for the overhead share

What happens: The overhead share is calculated with the revenue ratio in one period and a different key in another; or the set of expenses included changes from period to period.

Why it is a problem: A change of key can read as a choice made to enlarge the refund, and a justification is requested during inspection.

How to prevent it: The key and the expense accounts in scope are defined once, documented and applied the same way every period.

6. Later corrections not reflected in the list

What happens: After the refund file is prepared, a purchase invoice is cancelled, a return is received or an accounting entry is corrected; the list stays as it was.

Why it is a problem: The list and the accounting records diverge. The difference often surfaces when the next period’s file is reviewed.

How to prevent it: Every later change to documents included in the refund file is flagged, and the period file it affects is reported.

7. No reconciliation between the return, the lists and the books

What happens: The file is submitted without comparing the VAT borne list total with the refund amount on the return, the deductible input VAT list and the ledger.

Why it is a problem: Even a small difference in totals is enough for a deficiency notice.

How to prevent it: A three-way reconciliation is made before submission: the VAT borne list against the deductible input VAT list, the lists against the ledger, and the lists against the return.

10-point pre-refund checklist

Before submitting the refund file, you should be able to answer "yes" to each of these questions:

• Was VAT borne calculated with actual consumption from production records?

• Is the justification for consumption that deviates from the standard recipe in the file?

• Was the used and remaining quantity of each purchase invoice tracked so it does not overlap with earlier periods?

• Is every export invoice matched with at least one customs declaration?

• Were open invoices and customs declarations listed separately?

• Were purchases under DİİB excluded from the calculation?

• Was the same key and the same set of expense accounts used for the overhead share as in earlier periods?

• Was any document cancelled or corrected after the file was prepared, and if so, is the change reflected in the list?

• Does every invoice on the VAT borne list appear on the deductible input VAT list and in the ledger?

• Do the list totals equal the refund amount on the VAT return?

The first eight points check the accuracy of the calculation and the last two check the consistency of the file. Done by hand every period, these checks can take days, which is why turning them into rules is the step that shortens refund time the most.

Building these checks into one flow in SAP

What the seven errors have in common is that data is pulled out of different SAP modules every period and combined in Excel. Production consumption comes from PP, inventory and the DİİB separation from MM, purchase invoices from FI, and export and customs declaration data from sales and foreign trade processes. In Excel, every combination is rebuilt from scratch, and information from earlier periods, such as how much of an invoice has been used, stays in separate files.

The picture changes when the checks become rules inside SAP:

Error	Once it becomes a rule in SAP
BOM vs. actual consumption gap	The calculation is built from actual consumption on production orders; variances are reported automatically
Duplicate allocation	The used quantity is kept permanently at invoice line level; a second use is blocked
Invoice vs. customs declaration mismatch	Matching becomes a permanent record; open items are listed every period
DİİB separation	Certificate purchases are separated at inventory level and excluded from the calculation
Inconsistent allocation key	The key and expense accounts are defined once and run the same way every period
Later corrections	Changed documents are flagged; the affected period is reported
Missing reconciliation	List, ledger and return totals are compared before submission

Finpro İade KDV runs these checks inside SAP in a single cockpit. VAT borne is calculated from bill of materials and actual consumption data; customs declaration matching, DİİB separation, duplicate checks and reconciliations run in the same flow; and the GİB refund lists are prepared with every line linked to its source document.

Frequently asked questions

What is the deadline for a VAT refund claim?

For fully exempt transactions, a refund can be claimed until the end of the second calendar year following the year of the transaction. If the claim is made with a certified public accountant (YMM) report, the report must be submitted within six months after that deadline. Because deadlines can vary by transaction type, confirming them for each file with a tax advisor is recommended.

How is an error found after the lists were submitted corrected?

If the error affects the VAT borne amount, an amended return is filed for the period concerned and the lists are resubmitted. If the claim was made within the deadline, missing documents and information can be completed later. Which periods the correction affects can be determined quickly when it can be traced back from the source document.

How is duplicate allocation detected in an inspection?

During an inspection, the invoices on the VAT borne list are compared with earlier periods’ lists by date, serial number and supplier. This comparison reveals any case where the same invoice was used across periods beyond the VAT shown on it. Keeping the used quantity at invoice line level closes this risk before submission.

Are these checks still needed for files refunded with a YMM report?

Yes. The YMM report is based on the VAT borne calculation and documents prepared by the company. The cleaner the bill of materials, customs declaration matching and reconciliations, the shorter the reporting process and the fewer the requests for additional documents.

Conclusion

Most delays in VAT refund files come from seven recurring errors: the gap between the bill of materials and actual consumption, duplicate allocation, invoice and customs declaration mismatches, DİİB separation, an inconsistent allocation key, later corrections and missing reconciliation. Each of them can be prevented with data that already exists in SAP. When the checks are rebuilt in Excel every period, the risk remains; once they become rules inside SAP, the file is consistent at the first submission.

Let’s review your refund file together: you can request a demo on the Finpro İade KDV page. For the fixed asset layer, see fixed asset share calculation under Communiqué No. 55.

Sources

• Turkish VAT refund calculation: direct costs, overheads and fixed assets — Finpro Blog

• VAT General Implementation Communiqué — mevzuat.gov.tr (in Turkish)

• VAT refund lists — Revenue Administration (GİB, in Turkish)

• Calculating VAT borne — Muhasebetr (in Turkish)

• VAT borne in refunds — Muhasebetr (in Turkish)