The project had started two months earlier. A mid-sized textile export factory in Gaziantep, with 312 employees, had decided to move its inventory and accounting records from paper ledgers to a computer system. The software vendor had come in, delivered a presentation, signed a contract. The installation was done. But the accountant would not touch the keyboard. ‘This program is not for us,’ she kept saying. ‘The account codes are wrong.’ The owner walked in, frustrated. ‘We paid a lot of money. Why is it not working?’ Everyone in that room was talking about a different problem. But the root cause was the same: no one had genuinely brought Turkish accounting law into the project from the start.In Turkey, a business cannot assign account codes freely when keeping its books. The Uniform Chart of Accounts (Tek Düzen Hesap Planı, or TDHP), which came into force in 1994, specifies exactly which account carries which number. Cash sits at code 100. Trade receivables at 120. Trade payables at 320. These numbers are fixed by law. On top of that sits the Tax Procedure Law (Vergi Usul Kanunu, or VUK), which governs how ledgers must be kept, which documents must be recorded, and how a trial balance is drawn from the day book. A Turkish accountant is trained on these rules and works by these rules every day. If the software she is handed was not designed around these rules, it is useless to her. Full stop.So why do ERP projects keep missing this? Because most software vendors position their product as a ‘general’ solution. Programs developed abroad, or locally but built with export ambitions, try to bolt on a localisation module after the fact. On paper this sounds sensible. In practice it creates a specific problem: the list of account codes on screen does not match what the accountant has carried in her head for decades. When she goes to enter a day-book record, she cannot find the right code. When she prints a trial balance, the numbers look unfamiliar. It is like a market stall where the price tags are all there but every single one is on the wrong shelf. Everything exists; nothing is in its place.Here is the core argument — and it is worth stating plainly because it is commonly misread. Many people think: ‘Local accounting law constrains ERP.’ That is wrong. The correct reading is this: the law provides ERP with its backbone. What looks like a constraint is in fact a framework. And if that framework is read carefully at the beginning of a project, it becomes the clearest guide available. The TDHP account numbering tells you where receivables tracking begins, where inventory sits, how costs are split. Lay this on the table in the first week of implementation and you know which module to start with, in what sequence to proceed, and which field on which screen must be mandatory. Skip the law and say ‘let us install the technology first, then show the accountant,’ and two months later you will be the frustrated owner walking into that room in Gaziantep.I can share a representative scenario to illustrate the cost of this gap. A trading company began posting invoices into a newly installed system. But the VAT accounts had not been separated. The program was rolling VAT into the net sale price. Hundreds of invoices were posted incorrectly. Correcting them took longer than the original installation. What caused this? Not the program. At the start of the implementation, no one had brought VUK’s VAT recording requirement to the table. ‘Did the program not know about VAT?’ No — it knew. But during setup, nobody had mapped the legal requirement to the correct parameter. The law had not been read in advance. The accountant had assumed someone else handled it. The consultant had assumed the software handled it automatically. Nobody had handled it. This is not a technology failure. It is a project management failure rooted in treating local law as an afterthought.Now for the practical steps — because knowing the problem is only half the work. If you are about to set up computerised accounting in a factory or trading business, here is what Monday morning actually looks like. First step: sit down with your accountant and, if you have one, your cost accountant. Start from the paper ledgers and trial balances already in use. Which accounts do they use most? Which entry types repeat every single day — inventory receipts, invoices, bank movements? Write that list down before you open any software brochure. Second step: when evaluating programs, ask a specific question — not ‘does it have a chart of accounts?’ but ‘does it come preloaded with Turkey’s Uniform Chart of Accounts as defined by the 1994 regulation?’ The difference matters. Third step: check the VAT recording structure. In Turkey, VAT on a sales invoice is posted to a separate account — it is not embedded in the sales figure. Does the program handle this automatically, or does the user enter it manually every time? Find out before signing anything. Fourth step: put the accountant in front of the program for a real two-hour entry session — not a vendor demonstration, but actual data entry using your own documents. Two hours of real work reveals what no presentation ever will.Back to the factory in Gaziantep. The accountant’s reluctance to touch the keyboard was not laziness. The codes on screen were not speaking her language. Fixing the project took two weeks — two weeks that could have been saved if the law had been genuinely read at the start. This was not a technical installation problem. Either no one with real knowledge of VUK was involved in the project, or someone was involved but not listened to. I ask the same question at the start of every similar engagement today: does at least one person in the room know the relevant articles of VUK? If the answer is no, stop the project. The technology can wait. The law does not.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 23, 2001. The English edition has been reviewed and edited by the author.