Software Registered with the Israel Tax Authority: What It Means for a Custom System

The registry of software for managing accounting systems registers a software product, not the business using it. A registration is identified by a number that appears inside the file the software produces, and the central condition for registration is that the software embeds a module producing uniform-format files. For a custom build, the first question is who the software is for.

What gets registered, and what does not

The registered entity is a product: software name, edition, vendor. The registry also lets businesses that use accounting software check data about the validity of registration certificates, so it works in both directions - a buyer can check whether the tool being sold to them appears there.

What is not registered: not the business, not the specific installation, and not the customisations built for one client. That is the confusing part in custom development projects, because the registration describes the product as sold, while the system in the field usually includes layers built around it.

Which form is filed and what goes with it

The application is filed digitally in the software-house area, and when choosing a digital-actions permission you tick the request to register accounting software. A software house that is a corporation has to register the corporate details and grant a digital permission to whoever acts on its behalf; a self-employed individual is not required to register corporate details.

According to the Tax Authority's own training material, the registration request is accompanied by:

1. A declaration that the uniform-format generation module has been applied in the required version.
2. A summary report output from the simulator, evidencing that the file the software house uploaded passed the check.
3. A uniform-format file containing samples of every document type and every record type - B100 and B110 in bookkeeping, C100, D110, D120 in sales and purchasing, and M100 in inventory.
4. At least ten whole documents of each document type, meaning a header record plus its detail or receipt records.
5. The accompanying printed forms that the software generates as part of the export.

The order of magnitude cited in that material is roughly two thousand records in a file of up to about 1MB. Take the exact module version and the binding list of attachments from the current publication, because both have changed over the years.

Does an in-house system built for one business need to be registered?

Factually: the registration obligation is described in relation to producers of software intended for sale, rental or use by others. A system built for one business and used only by it is not that case, and the requirement that continues to bind it is the ability to produce uniform-format files, which derives from the bookkeeping instructions rather than from the software registry.

That is a statement of the published position, not an opinion. The determination for one specific system - what exactly it does, whether it is resold, how it is classified - is made with your accountant and with the Tax Authority.

Where the registration number actually shows up

Not as a certificate on the wall, but as fields inside the file. The central record in INI.TXT carries the identity of the tool that generated it:

This is also why an export layer built separately from the system is not "registered software" in its own right: it has to write values into those fields that somebody is accountable for.

Why the question surfaces mid-project

Because it is almost never asked at the start. A project begins as an orders screen or a process automation, and somewhere along the way somebody asks that the system also issue an invoice, or store a journal entry, or replace the spreadsheet where the books were actually kept. At that moment the question changes shape - it stops being about what the system displays and becomes about what it maintains.

Three decision points worth spotting early:

• The system starts producing documents with accounting meaning rather than summarising existing information.
• The client stops entering the same data into the existing accounting system as well.
• Somebody asks whether this could be sold to another business.

Each of those changes the answer. The third is the one that brings the software registry into scope, which is why it belongs at the start of the project rather than after launch.

What happens to software that is not registered

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 in the registry and does not produce files in the required structure is regarded as not meeting the requirements of the bookkeeping instructions. That is why the question surfaces in a development project at all - not because of the front end, but because of what the system holds behind it.

How do you check whether a given product is registered?

Through the registry search service on the Tax Authority site. It is a check worth running while selecting a vendor rather than after signing, alongside the ordinary commercial questions covered in choosing between an ERP module and custom development.

Worth settling before any building starts:

• Whether the planned system replaces the books of account or sits on top of them.
• Who produces the uniform-format file today, and in which version.
• Whether the product is intended to be resold, and when that decision gets made.
• Who owns updating the edition when the specification changes.

If you arrived at this question because the existing system produces nothing at all, the practical side is in producing a uniform-format file from a legacy system, and background on the file contents is in what a BKMVDATA file is.

Sources

• Application to register software for managing a computerised accounting system - Israel Tax Authority
• Search the registry of software for computerised accounting systems