Your legacy system has no uniform-format module. What to build - the OPENFRMT folder, two files and verification printouts - and how to test it in the simulator.
Key takeaways
- The amendment to the bookkeeping instructions was published on 2 August 2006 and took effect on 1 January 2008.
- The output is a folder named `OPENFRMT` on the drive the user picks, with sub-folders by business number, year and generation time.
- The Tax Authority's own guidance says the generation option must sit no more than one step from the main menu.
- Writing the file is not the whole module - printed verification outputs are part of the requirement.
- The file-checking simulator accepts a file of roughly up to 1MB and returns a summary output.
When an older system ships no export module, the answer is a generation layer that reads the underlying database and writes both files to the specification. It is not hand-writing lines into a text file: it is a repeatable process with a documented field mapping, verification printouts, and a simulator check before anything is handed over.
What has to exist when the run finishes
A clean run produces two files in the same folder. INI.TXT is the leading file: it opens with a record coded A000 that carries the identifying details of the business and of the software that generated the export, followed by summary records - one per record type present in the data file, each carrying the count of transactions of that type. BKMVDATA.TXT is the data file: it opens with an A100 record, closes with Z900, and holds the data records in between.
That central INI.TXT record is where most in-house systems fall over, because it demands values that have no source anywhere in the business database - a system constant with the value &OF1.10&, the software registration number, the software name and edition, the VAT number of the software vendor, the software type and the bookkeeping type. Those are facts about the tool doing the generating, not about the business.
What the output folder looks like
The files do not go wherever is convenient. The layout is fixed: a folder named OPENFRMT beneath the root of the drive the user selects at run time, containing a sub-folder that combines the business number with the year, and beneath that a sub-folder stamped with the generation date and time down to the minute.
The practical consequence is that every run lands in its own folder and never overwrites a previous one. That sounds like a trivial implementation detail, and it is the single thing that lets you fix a value at source and regenerate without losing the version already handed over. Take the exact character order of the timestamp folder from the current edition of the instructions - it has appeared in two different orders across Tax Authority training material.
Can you keep running a system that cannot produce the file?
That is a question for your accountant, not your developer. What can be stated factually is this: the Tax Authority director's notice set 1 January 2008 as the date from which software for managing a computerised accounting system that is not entered in the registry and does not produce files in the required structure is regarded as not meeting the requirements of the bookkeeping instructions.
This is a technical description, not tax or accounting advice. What it means for one specific business, system and level of activity is a question for your accountant and for the official source.
What the module owes you beyond the file itself
The guidance also defines verification outputs, and this is exactly the part that gets skipped when someone improvises an export script:
- A visual output covering the date range that was generated. In software that includes a bookkeeping module, that is a transaction trial balance.
- A report covering each document type, with the number of documents and their monetary total. A document type the software does not manage is filled with zero.
- A completion output. The business number, the business name, a message that the open interface finished successfully, the path where the data was saved, and the date range generated.
The second output is the real control. An order line showing 120 documents and a total, sitting next to a delivery note line showing a count and a zero amount, tells you plainly what the system manages and what it does not - before anyone opens the file.
Getting data out of an old system without breaking it
- Work on a copy. A backup or snapshot of the database, never the live file.
- Read only. The generation layer writes nothing back to the source system.
- Write the mapping down explicitly: which table and which column feeds each field in each record. The mapping is a document, not a code comment.
- Produce an exceptions report before writing anything - documents with no lines, customers with no identifier, dates outside the range.
- Regenerate after every fix at source, instead of editing the output.
Old Access systems add difficulties of their own: Hebrew encoding, date columns stored as free text, and document numbers that are not sequential. Each of those produces a file that looks fine and fails on import. If the legacy system is on its way out anyway, read the Access to web system migration plan before investing in an export layer you will throw away.
How do you know the file is valid before handing it over?
You run it through the Tax Authority's file-checking simulator. The simulator emulates the file intake process, gives feedback on whether the file structure matches the specification, and produces a summary output describing the result of the check. It accepts a file of roughly up to 1MB, so you check a representative date range rather than the whole history.
| Stage | What you check | What you do on failure |
|---|---|---|
| Before generating | Exceptions report on the source data | Fix it in the source system |
| After generating | Printed outputs against the live system | Trace the missing document type |
| Before handover | The simulator output | Fix the mapping and regenerate |
| Handover | The file plus the printouts | Keep a copy of the folder exactly as delivered |
How this connects to software registration
If the tool you built is also meant for anyone other than your own business, an entirely separate subject appears - the software registry. The software details written into INI.TXT, starting with the registration number, come from there. What that means in practice is covered in software registered with the Tax Authority, and background on the file contents themselves is in what a BKMVDATA file is.
Sources
Frequently asked questions
Can I just export to Excel and convert it?
Not in a way that holds up. An Excel export shows what the screen shows, while the file requires complete records including document-to-line relationships and summary records. A one-off conversion may pass once and will break next month when somebody changes a column.
How long does it take to build an export layer for an old system?
Almost entirely a function of the mapping, not the writing. If the data model is documented and the document types are clear, the engineering is short. Most of the time goes on establishing what each field in the old system actually holds and where its meaning drifted over the years.
Do I have to generate the whole history at once?
Generation runs on parameters: the business number, the target drive, and a date range or tax year. You can generate a slice. The simulator takes a slice anyway because of the size limit, and whoever asked for the file decides the range that actually gets handed over.
What do I do when the file is rejected with no clear reason?
Keep the simulator output, the printed verification outputs and the folder exactly as generated, then compare the transaction counts in the summary records against the real counts in the data file. A count mismatch is the most common failure, and it points at the mapping stage rather than at the file.
Keep reading
Related service
Access & Excel Rescue
Stabilise the file the business runs on, then fix it or move it to the web.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.