Custom ERP development in Israel
Three honest options, how the local accounting and invoicing stack decides between them, and the parts of an ERP proposal that tell you in advance whether the estimate will hold.
In short
The build-or-buy question is usually the wrong question, because the answer that works is both: a packaged system for the regulated core, where someone else is contractually obliged to follow changes in the law, and custom software only for the part of your business the package cannot describe. What decides the cost of either path is the number of integrations and the state of the data you are migrating. Module counts and user counts are what proposals estimate because they are easy to count, and they are not what moves the date.
Three options, not two
Every ERP conversation starts as a binary and the binary is false. There is a third position, and it is where most companies that are satisfied with the outcome ended up.
| Approach |
Fits when |
Where it breaks |
What you own at the end |
| Packaged, configured |
Your operations resemble the rest of your sector and the differentiation is in the product or the sales motion, not the process |
At the first process that the vendor's data model has no column for. The workaround becomes a spreadsheet, and the spreadsheet becomes the real system |
A subscription and your data in someone else's schema. Check the export format before you sign, not after |
| Packaged core plus custom edge |
Most companies. Finance and payroll are regulated and should be someone else's obligation; the part that makes you money is yours |
At the boundary, if the boundary was never drawn. Two systems both believing they own the customer record is the most common failure in this shape |
A smaller custom system that you can change, and a package you can replace without rewriting the part that matters |
| Fully custom |
The process is the product. Manufacturing with a scheduling model nobody sells, logistics with your own routing rules, a regulated niche no vendor serves |
On the regulated core. Payroll and tax reporting change by legislation, not by your roadmap, and now tracking them is your job forever |
Everything, including the obligation to follow the law yourself |
The second row is not a compromise between the other two. It is a different decision: it treats "which parts of this must I be free to change" as the design question, rather than "which vendor wins".
What makes this different in Israel
The ERP is the same software it is anywhere. Three things around it are not, and each one adds work that offshore estimates routinely omit.
The accounting layer is a local market
Israeli finance teams work with local accounting systems, and your ERP will exchange files with whichever one your accountant already uses. That exchange is a real integration with its own formats and its own idea of what a valid record looks like. It is also non-negotiable in practice, because the party on the other side of it is the one who signs off your books.
Invoicing is becoming a conversation, not a write
Israel is moving invoicing toward issuance that requires a response from the tax authority before an invoice is valid for deduction. This matters architecturally more than it sounds. Creating an invoice stops being a database insert and becomes a call to an external service that can be slow, can fail, and can refuse. Any system that treats invoice creation as synchronous and local will need to be rebuilt at that point, and the rebuild reaches the parts of the code that are hardest to change.
The question to ask a vendor. Not "do you support it" but "what does your system do when the authority does not answer". If the answer is that the user sees an error and retries, the invoicing flow has not been designed, and your finance team will discover that at month end.
Bilingual is a data problem, not a UI problem
The same customer has a Hebrew legal name for local documents and a Latin name for international ones. The same product has both. Treating this as a translation layer over a single name field produces documents that are legally wrong in one language or the other. It belongs in the data model from the first migration, because retrofitting it means touching every document template you have built.
Right-to-left rendering is the easy half of this and the half everyone budgets for. The hard half is sorting, searching, and matching across two scripts, and reports that have to total correctly when a column contains both.
What decides the schedule
Two numbers, and you can measure both before committing to anything.
- How many systems have to agree. Count every place a record is created today: the accounting system, the bank feed, the warehouse, the shop, the spreadsheet on someone's desktop that reconciles two of the others. Each one is an integration, and each integration has an owner who must be available during the project.
- How clean the data is. Take the three records your business argues about most, usually customer, product, and order, and extract a few hundred of each. Run them through the candidate system. Count the fields with no destination and the records that fail validation. That count is the data-cleaning project, and it is work that happens whether or not anyone planned it.
Notice that neither number is about the ERP. This is why platform comparisons are a poor way to start: the platform affects the part of the cost that varies least.
Failure modes visible in the proposal
- A go-live date fixed before anyone looked at your data. The date is then met by moving scope, and the scope that moves is always data quality, which is the part that determines whether people trust the new system.
- No line item for data cleaning. It is usually the largest single piece of work and the easiest to leave out of a competitive bid.
- A demo on the vendor's sample company. Ask for the demo to be rebuilt on an extract of yours. The willingness to do that, more than the demo itself, is the signal.
- No reversal plan. Ask what happens if the cutover is undone after two days of live use. A plan has an answer; a schedule does not.
- Training counted in hours rather than in roles. The warehouse and the finance team need different systems explained to them, and one of the two groups usually gets neither.
Why companies with a working ERP replace it anyway
Rarely because of features. The reasons that actually appear are narrower and worth recognising in yourself.
The system cannot be changed at the speed the business changes. Every modification goes through a queue outside the company, and so the business routes around the system instead. The data cannot leave. Reporting requires exports, exports require manual repair, and the repaired version becomes the number the board sees. A single person understands the configuration and that person is a risk nobody has written down.
These are architectural complaints, not functional ones, and a replacement chosen on a feature matrix tends to reproduce all three.
How I work on this
Practice since 2004, work on AI systems since 2023, projects for clients in fourteen countries. I am an independent architect rather than a reseller, so I have no implementation licence to protect and "configure what you already own" is a legitimate conclusion of a review. It is also, often enough, the correct one.
What a review produces: the integration count, the result of running your own data through the candidate systems, a build-buy line drawn per business area rather than for the whole company, and the order of work with the risk named per step. What it does not produce is a vendor recommendation before those numbers exist.
SLAtech LTD