When a business replaces Rivhit with Hashavshevet H-ERP: inventory, manufacturing, branches, costing and users. The signs, what you gain, and what costs more.
Key takeaways
- The trigger is not turnover but complexity: bills of materials, manufacturing, branches, and job-level costing.
- Hashavshevet presents modules with no counterpart in an invoicing system: production floor, service labs, fixed assets, rental management.
- It also presents a detailed interface layer - ODBC and text-file import, bank statements per bank, stock counts, an e-commerce interface.
- The real cost of a migration is implementation and data, not the licence.
Rivhit and Hashavshevet are not two equal options you choose between once - they are two stages. Rivhit is a product family for running a business and its bookkeeping; Hashavshevet H-ERP is an ERP with modules for purchasing, inventory, production floor, costing, service labs, rentals and HR. The move happens when operations break, not when bookkeeping does.
What Hashavshevet presents that an invoicing system does not
| Module | What it does | Why it is a migration trigger |
|---|---|---|
| Purchasing, inventory and sales | The order-delivery-stock cycle in one system | Spreadsheet inventory breaks once there are bills of materials and counts |
| Production floor | Managing manufacturing itself | You cannot manufacture against an invoicing system |
| Payments system - cheques and Masav | Supplier payments and collection | Masav files and cheques managed in the system rather than at the bank |
| Recurring charges | Subscriptions and repeat billing | Regular collection at a volume that needs a module |
| Service labs | Calls, repairs and warranty | A service business with products that come back for repair |
| Rental management | Contracts and rental income | Income that does not come from a sale |
| Hourly client billing | Billable hours, per client | Practices and projects |
| Fixed assets | Asset register and depreciation | An accounting requirement an invoicing system does not cover |
| POS tills | Points of sale | Shops and branches |
| CRM | Customer relationships inside the same system | Sales that need to sit next to inventory |
Alongside these, Hashavshevet also presents an additional product layer - H-WEB, H-BI, H-MOBILE, H-BPM and others - and a documented interface layer. That is a difference in character: a system expected to have things connected to it, not a closed one.
What are the signs, in practice?
Not turnover. These are the signs:
- Inventory that stopped being a list. Bills of materials, components, periodic counts, warehouse locations.
- Manufacturing or assembly. Even simple assembly from components counts here.
- Several branches. Different price lists, per-branch permissions, and a report that has to break down.
- Costing. The question "how much did we make on that job" with no answer in the system.
- Payroll and HR managed in three places.
- Several users working in parallel on the same data, needing real permissions.
- Reports somebody rebuilds in a spreadsheet every month from the same two files.
The seventh sign is the most reliable of all. A monthly spreadsheet somebody maintains is a shadow system, which means the official one does not meet the need.
What costs more than it looks
Moving to an ERP is not a software swap but a project, and these are the components that surprise people:
- Data. Cleaning customer, supplier and item records before loading. This is almost always the long phase.
- Implementation and training. A deep system needs someone to learn it. A business that does not invest here returns to spreadsheets.
- Customisation. Reports and documents adapted to what the business actually does.
- Interfaces. Connections to the store, to clearing, to payroll and to the bank - each a job of its own.
- Your professionals' time. The accountant and bookkeeper need to be in the process, and that is hours.
Hashavshevet presents detailed interface documentation - import from an ODBC table, import from a text file, bank statement import per bank, item and bill-of-materials import, stock counts, and an e-commerce interface. That is a good planning starting point, but the planning itself still has to happen - the technical side is in the Hashavshevet API guide and what breaks on import is documented in Hashavshevet import errors and reconciliation.
What not to do in a migration
- Do not migrate mid tax year if you can avoid it. Starting at the beginning of a year simplifies balances, numbering and reports, and is worth waiting two months for.
- Do not migrate and adopt a new module in the same week. If operations move and the production module goes live for the first time, you will not know what broke.
- Do not switch the old system off immediately. You need it readable at least until year-end closing, sometimes longer.
- Do not let the project run without an owner inside the business. The implementation vendor brings expertise; deciding what matters is yours, and no vendor can decide it for you.
The first point is the only one hard to fix afterwards, so if you are reading this in September, planning for the start of the year beats pushing now.
What to do before deciding
- Write the seven signs down and mark how many are true for you. Three or more is a real discussion.
- Ask your bookkeeper and accountant what they work against and what would make their life easier.
- Ask for a demo on your own process, not a generic one. Bring a real document and a real order.
- Establish what happens with allocation numbers, the uniform format and the VAT report in the new system - basics, not extras.
- Check what can be exported from the current system before you start.
- Decide what does not move. Ten years of history does not have to enter the new system.
That last item saves most of the time. History is kept in a readable archive; the new system needs opening balances and live data, not a decade of transactions.
That last line deserves emphasis: a good implementation vendor will ask you questions you have no answer to, and that is a good sign. A vendor who asks nothing and promises everything will work exactly as today is selling you an installation, not an implementation.
Sources
Frequently asked questions
What determines when to move to an ERP?
Operational complexity, not turnover. A business with high turnover and one product can stay on a simple system; a small business with manufacturing, complex inventory and two branches already needs one. The practical test: how many shadow spreadsheets somebody maintains each month.
Can I stay on Rivhit and just add modules?
Rivhit presents a product family and paid modules, so sometimes that is the right answer - particularly where the need is payroll, Masav or bank statement import. That beats a full ERP project while operations themselves are not yet complex.
What is the most expensive part of a migration?
Data and implementation. Cleaning customer, supplier and item records is the long phase, and training decides whether the system actually gets used. The licence is the component you can budget up front; the other two are the ones that overrun.
Do I need to migrate all the history?
Almost always no. You need opening balances, active items, customers and suppliers, and open balances. The history itself can stay in a readable archive and a backup, subject to retention obligations - which also saves most of the migration time.
Keep reading
Related service
Data Migration
Move systems without losing the history - mapping, pilot, delta, cutover.
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 and I'll tell you the fastest reliable way to ship it.
