What Is SAP E-Beyanname? Turkish Tax Declarations from SAP

For companies running Turkish entities on SAP, preparing tax declarations usually means living in two worlds: the figures sit in SAP, while the declarations take shape in spreadsheets and in the tools of Türkiye’s Revenue Administration (GİB). An SAP E-Beyanname solution removes that gap: declarations are prepared from SAP data, validated and approved inside the company, and managed for filing through the applicable GİB channel in a single flow. GİB’s phased rollout of its e-Beyan REST API is making this approach practical for a growing set of declarations.

Why the usual process wears teams down

A typical period-end works like this: the team extracts balances and documents from SAP, builds the tax figures in a spreadsheet, and carries the result into GİB’s Declaration Preparation Program (BDP) or portal. Three structural problems follow:

The same data is moved by hand, repeatedly. Every copy step adds error risk and overtime.
Validations depend on individuals. Base-to-rate reconciliation, tax-account balances, and carried-forward VAT checks vary with whoever built the file that month.
Traceability is expensive. Showing an auditor which SAP document produced a declaration line can take hours.

What is an SAP E-Beyanname solution?

SAP E-Beyanname is a solution layer that runs inside SAP: it assembles declaration data from SAP FI and related sources, routes it through internal validation and approval, and manages filing through the applicable GİB channel — together with the returned assessment and status documents — in one transaction trail. Rather than separate middleware, it can be implemented with native ABAP architecture on the company’s existing SAP ECC or S/4HANA system.

On scope, the solution can be adapted to cover VAT 1 (KDV 1), VAT 2 (KDV 2), withholding and social-security premium (MUHSGK), stamp duty, provisional corporate tax, and corporate income tax processes. “Adapted” is deliberate: whether a given declaration can be filed for a given period through a given channel depends on GİB’s phased rollout calendar, the taxpayer’s authorization, and the working environment. The declaration, period, and filing-channel scope guide covers how that decision is made.

How the end-to-end flow works

The core chain is:

Data preparation → internal validation → approval → GİB channel → status tracking and archive

Data preparation: Declaration lines are assembled from SAP FI documents, account balances, and related payroll or tax sources; every line traces back to its source.
Internal validation: Mandatory-field, base-to-rate, account-balance, and carried-forward VAT checks run before any official step; blocking differences stop the process.
Approval: Preparer and approver are separated; who approved what, and when, stays on the transaction trail.
GİB channel: Depending on scope, the e-Beyan REST API or the applicable package/BDP flow is used; each declaration proceeds through a single channel.
Status and archive: The GİB response, assessment, and approved declaration are archived with the declaration ID, period, and company code.

For the technical layers, see the SAP E-Beyanname integration architecture.

What it delivers

One transaction trail: Every step from preparer to GİB response lives on the same record; audit questions are answered in minutes.
Errors caught early: Inconsistencies surface during internal validation, before official approval; the odds of a GİB error response drop.
No more manual carrying: Within the enabled scope, the SAP → spreadsheet → BDP copy chain closes.
Segregation of duties: Preparation, validation, approval, and submission authority are separated; exceptions are recorded.
Versioned compliance: GİB schema and rule changes are managed through versioned mappings; past periods keep their rules.
Audit-ready archive: Approved declarations and assessment documents stay searchable in the archive.

Read “supported” carefully

The most common mistake in this space is reducing scope to a one-line promise. Instead of “all declarations are supported,” ask for a declaration–period–province/taxpayer–channel matrix, and read the GİB e-Beyan REST API vs. BDP comparison on the roles of the two channels. A serious solution can show, in writing, what works under which conditions.

How to start

Authorization and application: If the REST API is the target, the e-Beyan integration application is filed through the Digital Tax Office; approved IP addresses and per-environment API keys are planned.
Scope matrix: Which declaration is filed for which period, through which channel, is put on record.
Project plan: Follow the SAP E-Beyanname implementation checklist for data mapping, validation, testing, and go-live.

Fenikstech’s SAP E-Beyanname solution brings this entire flow together in a single cockpit inside SAP. To walk the process end to end with sample screens, explore the interactive simulation of the SAP E-Beyanname solution.

Official sources

This article was reviewed against the official sources on 23 July 2026.