A global ERP system does not become Turkey-ready by switching the language to Turkish. Statutory books must follow a prescribed chart of accounts, invoices must be issued through the tax administration’s electronic platform in a prescribed format, ledgers must be produced as electronic files with certification records, and several Turkish mechanisms — partial value added tax withholding, inflation adjustment, prescribed depreciation lives — have no equivalent in a standard configuration.
We work on the accounting side of ERP projects: designing the chart of accounts so that it satisfies both the statutory format and the group’s reporting structure, specifying the electronic document integration, and running the parallel period before cutover. For the underlying bookkeeping and reporting service, see accounting services in Turkey.
What a Global ERP Must Handle to Work in Turkey
These are the requirements that a standard international configuration does not meet, and they are the reason ERP projects in Turkey overrun. None of them is optional.
| Requirement | Why a standard configuration fails |
|---|---|
| Uniform chart of accounts | Account codes, their numbering and the format of the statutory financial statements are prescribed by legislation. The group chart must be mapped onto it, which means the mapping has to be designed before go-live, not reconciled afterwards |
| Electronic invoicing | Invoices are issued as structured files through the tax administration’s platform. Numbering follows a prescribed sequence and cannot simply continue the group’s numbering |
| Electronic ledgers | The journal and general ledger are produced as files in a prescribed format, with certification records uploaded within set periods. This is an output requirement, not a reporting preference |
| Partial value added tax withholding | For certain supplies the buyer withholds part of the tax and accounts for it separately. Standard tax engines model a single rate per line and do not split it between the parties |
| Prescribed depreciation lives | Useful lives are set for tax purposes and rarely match group policy, so the system must carry two depreciation bases rather than one |
| Foreign currency valuation | Transactions and period-end valuation use officially published rates rather than the group’s rate table |
| Inflation adjustment | Where the statutory conditions are met, non-monetary items, the depreciation base and the taxable result are all adjusted under a prescribed methodology with no group equivalent |
| Non-deductible expenses | Items that are ordinary costs for group purposes are added back for tax, so the system needs to tag them at entry rather than identify them at year end |
Most difficulties in a Turkish ERP implementation trace back to a single early decision: whether the statutory chart of accounts is built into the system or bolted on afterwards through a mapping table maintained outside it. The second approach works until the first audit, a tax inspection or a due diligence exercise, at which point the statutory figures have to be traced line by line to the system and the mapping becomes the weakest link.
Designing the chart so that it satisfies the prescribed structure and still rolls up to the group’s reporting lines is more work at the start and considerably less work every month afterwards. It is also the part of the project a software vendor is not positioned to advise on.
Electronic Document Integration
An ERP does not connect to the tax administration on its own. Two routes exist and the choice affects cost, control and how quickly a change can be made.
The ERP connects to an authorised provider that handles transmission, validation, archiving and the certification files. Faster to implement, and regulatory changes are absorbed by the provider rather than by an internal project.
The company integrates with the administration directly. It removes a per-document cost at high volume, but every regulatory change becomes an internal development task with a fixed deadline.
Whichever route is used, the same points need specifying before development starts: the invoice types in scope, the numbering series, how counterparties are checked against the registered user list, what happens to a rejected document, and how the archive satisfies the retention period once the subscription ends. That last point is regularly missed — an archive that exists only inside a service that can be cancelled is not an archive.
Choosing a System
The right question is not which system is best but which constraints apply. These are the criteria that decide it in practice:
- Whether the group already mandates a platform
- Availability and maturity of the Turkish localisation
- How electronic documents are integrated, and by whom
- Whether the statutory chart of accounts is native or mapped
- Support for two depreciation bases and two reporting frameworks
- Whether payroll is in scope or handled separately
- Cost of a regulatory change after go-live
- Whether local accountants and auditors can work in the system
The last criterion is worth weighting heavily. A system that no local professional can operate turns every routine question into a support ticket, and the cost of that appears in the second year rather than the first.
Payroll Is Usually a Separate Question
Turkish payroll is calculated on a cumulative basis across the year, with income tax brackets, statutory minimum exemptions, several social security categories and incentive schemes that change annually. Global payroll modules rarely handle it correctly, and the errors are not visible until a filing is rejected or an employee’s net pay moves unexpectedly mid-year.
In most implementations payroll runs in a local system and posts summarised journals into the ERP. That is usually the right answer, and it should be decided at design stage rather than after an attempt to configure it centrally.
How We Work on an Implementation
- Define the statutory requirements firstChart of accounts, statutory statement formats, electronic document scope, tax codes including partial withholding, depreciation bases and currency handling. This is the specification the software is configured against, not something reconciled afterwards.
- Design the chart of accounts and the group mapping togetherA single structure that satisfies the prescribed format and rolls up to the group’s reporting lines, agreed with the group’s finance team before configuration begins.
- Specify the electronic document integrationRoute, document types, numbering series, counterparty checks, rejection handling and archive arrangements.
- Prepare opening balancesMigrated at the account level required by the statutory chart, with the supporting detail retained. Ledger continuity has to be demonstrable across the cutover.
- Run a parallel periodOne full month closed in both systems and reconciled line by line, including the returns. This is the step most often cut for time, and the one that surfaces configuration errors while they are still cheap.
- Cut over and close the first period in the new systemWith the returns, the electronic ledger files and the certification uploads produced from the new system and checked before the deadlines rather than at them.
Mid-year changes of system are possible but expensive. The electronic ledger files and their certification records must form a continuous series for the whole period, and a mid-year cutover means producing part of the year from one system and part from another, then demonstrating that the two join. Where the timing can be chosen, the start of an accounting period removes the problem entirely.
Where it cannot — an acquisition, a group mandate — the ledger continuity and certification arrangements should be planned before the migration date is fixed, not after.
Frequently Asked Questions
Can a global ERP be used in Turkey without local adaptation?
Should the statutory chart of accounts be native in the system or mapped?
How does an ERP connect to the electronic invoicing system?
Should payroll run inside the ERP?
When is the best time to change ERP systems?
Why does the system need two depreciation bases?
What happens to the archive if we stop using the service provider?
Do you implement the software yourselves?
As the Ozbek CPA team, we work on the accounting side of ERP projects in Turkey — designing the statutory chart of accounts and its mapping to group reporting, specifying electronic invoice and ledger integration, configuring tax codes including partial withholding, preparing opening balances, running the parallel close and taking responsibility for the first statutory period in the new system. Contact us.
