Hashavshevet or Priority: The Signals That Justify Moving

Hashavshevet and Priority are not two different leagues. Both manage books, inventory and business processes, and the question is not which is "bigger" but where the centre of gravity of your business sits: in the books and reporting, or in operations made of several interdependent processes.

What each system actually does

Hashavshevet is a long-established Israeli product - the company was founded in 1985 - presented today as H-ERP, covering bookkeeping and financial management, inventory, purchasing, marketing and CRM. Its historic strength is the books and the working relationship with accountants: a familiar accounting structure, long standing with Israeli practitioners, and reporting.

Priority is a modular ERP built around flow between processes - orders, production, purchasing, inventory, costing and projects - with a customisation and development layer delivered through implementation partners.

Which signals justify a move?

Not one. Three or more of these:

• Your process crosses four departments and nobody sees it end to end.
• There is production or assembly with BOMs and batches, not just buy and sell.
• Costing is needed per order or per item, not just overall gross margin.
• Projects with milestones, hours and budget versus actuals.
• Several companies or branches needing consolidated and separate reporting at once.
• Dozens of users with materially different permissions.

One or two signals and it is nearly always right to stay and fix the process, or add a layer - as described in replacing the ERP versus adding a calculation layer.

What is not a reason to move

• "The system looks old." An old screen is not an operational failure, and it is the most expensive thing to decide on.
• "We were told everyone is moving." Moving from what, and for which process.
• "We have a lot of invoices." Volume alone is solved by licensing and hardware.
• "Our accountant complains." Worth asking exactly about what - it is often a missing export, not a system.
• "Someone promised everything would be automatic." Automation follows process definition, not a system swap.

What does a sound migration look like?

1. Freeze the scope. Decide in writing what moves in phase one and what does not.
2. Settle the accounting structure with your accountant before entering anything.
3. Clean the data - customers, suppliers, items - before the export, not after.
4. Load opening balances and reconcile them against the final trial balance in Hashavshevet.
5. Run a parallel month if you can, at least for the main sales process.
6. Keep the old system available for viewing for an agreed period.
7. Cut over on a date aligned with the end of a reporting period, not mid-period.

Step 7 removes a great deal of duplicated reporting work, which is why the whole timeline is worth planning around it.

What happens to files and reporting?

Both systems operate in the Israeli environment and produce the outputs an accountant recognises, but the internal structure differs. Three points to settle in advance with the implementer and the accountant:

• The chart of accounts - copied as is, or rebuilt.
• The export to the accountant - in what format, at what frequency.
• History - how far back is loaded, and what stays view-only.

The second causes most of the friction after a cutover when it has not been agreed, because it touches someone else's working method.

What the move does to your team

The least measured aspect is the human one. A Hashavshevet installation that is a decade old usually has one person - a bookkeeper or an operations manager - who knows by heart where everything lives, including the workarounds built up over years. The move erases that knowledge at a stroke, and to that person it feels like a loss of competence.

Two things genuinely help. The first is to involve that person in the analysis from the beginning rather than presenting finished decisions - they know things about the process nobody else knows, and without them the configuration will miss. The second is to document the workarounds before they disappear: every "we write it in the notes field because there is no field" is a real requirement that needs a place in the new system, and if it is not recorded it will simply be reinvented as another workaround.

The sign that a migration failed on the human side is not open resistance but quiet: people keep working, and maintain their own file alongside. It is worth asking about explicitly a month after go-live, because nobody volunteers it.

What to ask your accountant before deciding

• Whether they work routinely with the system you are considering.
• What they receive from Hashavshevet today, and what they would receive afterwards.
• What is required of them during the transition, and what that adds to the cost.
• Which point in the year suits them for the cutover.
• What they need preserved from the old system, and for how long.

The fourth question alone can save a month of duplicated work, and it is almost never asked before the date has already been fixed.

The check that prevents the common mistake

The most common error in this decision is comparing a long-standing product whose every flaw you know against a new one you saw in a polished demo. That comparison is biased by construction: you know every weakness of the first and none of the second. The way to balance it is to ask both sides for the same thing - show us the three processes we struggle with most today, on our own sample data, rather than what you chose to present.

Sources

• Hashavshevet H-ERP - modules
• Hashavshevet - Hebrew Wikipedia entry
• Priority Software