Turkey VAT Withholding Invoice Requirements Guide

Turkey VAT withholding invoice requirements matter because a tevkifat invoice does not work like a standard Turkish VAT invoice. The seller still calculates and shows the full VAT on the document, but the buyer remits all or part of that VAT directly to the tax authority instead of paying the full VAT-inclusive amount to the supplier.

On a Turkey KDV tevkifat invoice, the key question is not whether VAT exists. It is how that VAT is split. A compliant invoice should separately show the transaction amount, calculated VAT, the withholding ratio, the VAT amount withheld by the buyer, the total including withholding, and the amount still payable to the supplier. Partial withholding only applies when the transaction meets the current invoice-threshold rule, so AP teams cannot assume every invoice in a listed category should be processed the same way.

That difference is where payment errors start. If your team reads the document like an ordinary VAT invoice, you can overpay the supplier, post the tax incorrectly, or miss the buyer's remittance obligation. The invoice may look familiar because it still contains a taxable base and VAT amount, but the cash outcome is different. One part of the tax stays in the supplier payment, another part shifts into the buyer's compliance workflow.

For finance teams, the practical workflow is to answer three questions in order: does withholding apply to this transaction, do the invoice fields support the split shown, and does the amount you plan to pay match the collectible amount after withholding? Treating tevkifat as an invoice-processing problem, not just a tax-definition problem, is what prevents downstream coding and payment mistakes.

When Partial or Full Withholding Applies

The first control point is classification. Partial withholding means the invoice shows full VAT, but only part of that VAT stays in the supplier payment. The buyer remits the withheld portion. Full withholding goes further: the buyer remits all of the VAT, so the supplier collects only the taxable base amount. If AP gets this decision wrong at the start, every later calculation and payment step is built on the wrong assumption.

In practice, the withholding ratio depends on the type of transaction. Finance teams should expect the ratio on the invoice to reflect the current Turkish rules for the underlying service or supply, not a ratio copied from a prior document. That makes the transaction description on the invoice important. A vague service line can hide whether the document belongs in a tevkifat workflow at all, and a copied template can carry the wrong ratio forward from a different type of job.

Thresholds need the same discipline. For partial withholding, the practical question is whether the transaction clears the current invoice-threshold rule referenced in Turkish guidance. If you are using this article to answer a Turkey tevkifat threshold question, verify the current year's figure from the latest Gelir Idaresi Baskanligi (GIB) material or related official guidance before relying on a hard number from an older article, ERP note, or spreadsheet template. If your controls store a fixed threshold in a checklist or bot, that value needs an annual review.

The operational lesson is straightforward: determine whether tevkifat applies first, then calculate the split, not the other way around. If the invoice category, buyer status, or threshold condition is wrong, the printed math can still look internally consistent while leading AP to post the wrong liability structure.

Which Fields a Tevkifat Invoice Must Show, With a Worked Example

At the document level, the reader needs a field checklist rather than a general definition. Turkey's VAT General Implementation Communique says tevkifat invoices should separately show the transaction amount, calculated VAT, withholding ratio, VAT amount withheld by the buyer, total including withholding, and the total amount collectible after withholding. Those are the core Turkey tevkifat invoice fields your team should expect to see before the invoice is approved.

Each field answers a different AP question:

• Transaction amount: What is the taxable base before VAT?
• Calculated VAT: What is the full VAT generated by the transaction?
• Withholding ratio: What portion of that VAT shifts to the buyer's remittance obligation?
• VAT withheld by the buyer: How much VAT should not be paid to the supplier?
• Total including withholding: What would the total be before the tevkifat split is applied?
• Amount collectible after withholding: What amount is still payable to the supplier?

A simple Turkey KDV tevkifat example shows why this matters. Assume the taxable base is TRY 100,000 and the full VAT is TRY 20,000. If the invoice applies a 7/10 withholding ratio, the buyer-withheld VAT amount is TRY 14,000 and only TRY 6,000 of VAT remains in the supplier payment. The total including withholding is TRY 120,000, but the collectible amount after withholding is TRY 106,000. That TRY 106,000 figure, not the full TRY 120,000, is the amount AP should be preparing to pay to the supplier.

That is the key Turkey tevkifat invoice calculation point. On a standard VAT invoice, teams often think in terms of base plus full VAT. On a tevkifat invoice, the payable amount is the collectible total after withholding. The worked example is illustrative, and the actual ratio must still match the transaction category on the live invoice, but the document logic stays the same.

If any of those fields are missing, merged into a single ambiguous total, or inconsistent with the printed ratio, the invoice should be reviewed before payment. A tevkifat invoice is only usable in AP if the document makes the VAT split auditable.

---

How AP Teams Should Validate and Pay a Tevkifat Invoice

Once the invoice is in the workflow, AP should validate it in a fixed sequence:

1. Confirm the transaction belongs in a tevkifat workflow.
2. Capture the tax base, full VAT, withholding ratio, buyer-withheld VAT amount, total including withholding, and collectible amount as separate data points.
3. Recalculate the withheld VAT amount from the printed ratio.
4. Approve payment only after the supplier-payable amount matches the collectible amount after withholding.

This is where the Turkey buyer withheld VAT issue becomes operational. The VAT shown on the document is not the same thing as the VAT the supplier will collect. If AP posts or pays against the full VAT-inclusive total, the supplier can be overpaid even when the invoice itself is correct. That is why tevkifat belongs in the same control family as other tax-sensitive document checks, including invoice validation rules for tax fields and totals.

Teams that manage multiple jurisdictions often need a second decision tree for cases where the buyer must distinguish between supplier-charged VAT, buyer-withheld VAT, and buyer self-accounting, which is why our guide to Nigeria withholding VAT vs self-account VAT is a useful comparison point.

In cross-border AP workflows, Peru's detraccion invoice checks are another good example of how tax controls can change the amount released to the supplier even when the invoice still shows the full transaction value.

The workflow also needs better data capture than a standard header scan. Because the withholding ratio depends on the transaction type, the service description and supporting line items may matter to the reviewer, not just the totals box. Teams should be able to trace the posted amount back to the exact page and field that supports it, especially when supplier layouts vary or when one vendor sends both ordinary VAT invoices and tevkifat invoices. When the transaction also involves a shipment of goods, the tax-side review may need to line up with the dispatch-side document trail, which this guide to Turkey's e-Irsaliye dispatch requirements outlines, and with whether the invoice should move through Turkey's e-Fatura or e-Arsiv flow.

That document-processing angle is what many explainers miss. Teams do not just need text recognition. They need the tax breakdown captured in a structured way, the payable amount separated from total VAT, and enough source-document evidence to verify how the split was derived. In workflows that already rely on AI invoice data extraction for complex VAT invoices, that can mean extracting invoice-level tax fields and line items into structured Excel, CSV, or JSON output while preserving source file and page references for review before posting the entry or releasing payment.

What Changes on Return or Credit Invoices

If you are looking for Turkey tevkifat return invoice handling, start with one rule: the return or credit document should mirror the original tevkifat treatment, not bypass it. If the original supplier invoice was subject to withholding, the reversal document needs to reflect the same logic for the taxable base, the VAT amount, the withholding ratio, the buyer-withheld VAT amount, and the net collectible amount. Treating the credit like a generic reduction in the supplier balance can leave the tax side out of sync with the original posting.

The control step is comparison. Put the original invoice and the return document side by side and check whether the reversal follows the same withholding structure. If the original document reduced the supplier payment because part of the VAT was buyer-remitted, the return document should reverse that structure consistently. Otherwise, the books may reverse only the supplier-payable amount while leaving the withheld VAT logic hanging in a separate tax record.

Partial returns deserve extra attention because they often tempt teams to shortcut the review. If only part of the original base is being credited, the related VAT and buyer-withheld VAT amounts should also scale consistently with that partial reversal. The safest approach is to check whether the return document still reproduces the same withholding logic as the original invoice rather than assuming the ERP will infer it from a negative total.

This is not unique to Turkey. If your team has dealt with another invoice withholding workflow in Europe, the same discipline applies here: a withholding-based document cannot be corrected safely unless the reversal follows the original withholding mechanics all the way through.

---

A Practical Checklist to Prevent Coding and Payment Errors

For teams using this article as a Turkey tevkifat invoice guide during day-to-day AP review, this is the checklist to use before posting or paying the invoice:

• Confirm the transaction actually belongs in a tevkifat workflow, and whether it falls under partial withholding or full withholding.
• Check the current year's threshold rule from current primary guidance before applying a hard figure copied from older documentation, onboarding notes, or ERP defaults.
• Verify that the invoice shows the transaction amount, calculated VAT, withholding ratio, buyer-withheld VAT amount, total including withholding, and collectible amount after withholding.
• Recalculate the withheld VAT amount from the printed ratio instead of trusting the payable amount blindly.
• Make sure the amount sent to the supplier is the collectible amount after withholding, not the full VAT-inclusive total.
• Review the service description and line-level context if the withholding ratio seems inconsistent with the transaction type.
• When processing a credit or return invoice, confirm that it mirrors the original tevkifat structure rather than reversing only the supplier balance.
• If your team also handles Italy's VAT split-payment invoice model, remember the same practical lesson: once tax mechanics change who remits VAT, AP has to separate tax treatment from the amount paid to the supplier.