Automating Hashavshevet and Rivhit: What Is Actually Possible

Two of the most common questions I get from Israeli businesses are "can we automate Hashavshevet?" and "can we push orders into Rivhit automatically?". They sound like the same question and they are not. Rivhit has a clear answer. Hashavshevet has five, and which one applies to you depends on facts nobody has written down.

Rivhit: The Easy Case

Rivhit exposes an HTTP API and behaves like a normal integration target. Typical work - creating documents, looking up customers, pulling document status - is straightforward, and a single well-scoped flow is usually a matter of days rather than weeks.

Two things to plan for. First, it covers invoicing rather than full ERP functionality, so if you need inventory, purchasing or production, Rivhit is one piece of a larger picture. Second, as with any financial system, document type selection is a bookkeeping decision that must be settled before code: an invoice, a receipt and a combined invoice-receipt are not interchangeable.

Hashavshevet: Find Out What You Have First

Hashavshevet is long-established, widely deployed, and installed in very different configurations across its user base. There is no single integration surface. Depending on your version, licence and deployment you may be working with:

The first task on any Hashavshevet project is to establish which of these you actually have. Ask your bookkeeper who supports the installation, then ask that person directly. This single answer moves the estimate more than any other factor.

Reading is safe, writing is not

If you have ODBC or database access, reading is genuinely useful and comparatively low risk. You can build reporting, feed a BI dashboard, reconcile against a CRM, or surface outstanding balances in an internal tool - all without touching the accounting data.

Writing directly to the database is a different matter. Accounting systems maintain invariants across multiple tables - document numbering, ledger balance, VAT records - and an insert that satisfies one table while violating another produces corruption that surfaces weeks later at reconciliation. If a supported API or import route exists, use it. If it does not, the honest recommendation is usually to keep writes manual, or to move the write side to a system that supports it.

File-based integration is underrated

Where a documented import format exists, it is often the most reliable option. It is slower and less elegant than an API, but it is a supported path, it produces an artefact you can inspect when something goes wrong, and it fails visibly rather than silently. For a nightly batch of documents, that is usually the right trade.

The Pattern That Works for Both

Regardless of surface, the same architecture applies:

1. Your own staging store. Incoming events land in your database first, with an external reference. Never translate a webhook straight into an accounting write.
2. A worker with retries. It drains staged records into the accounting system with backoff, and marks each with the resulting document identifier.
3. Idempotency keyed on your reference. Check before writing. A duplicate posted document is an accounting problem, not a data problem.
4. A visible error queue. With the payload and the error text, and a retry button.
5. Alerting on silence. If nothing has synced in two hours during business hours, someone should hear about it.

What to Do If You Are Choosing Now

If you are still selecting an accounting or invoicing system and integration matters to you, weight it heavily. The difference between a cloud system with a documented REST API and a legacy system with an uncertain integration surface is not a technical footnote - it is the difference between a one-week project and a two-month one, repeated every time you want to connect something new.

That does not mean migrating an existing installation is worth it. Migration carries its own cost and risk, and a working accounting system that your bookkeeper knows well has real value. But it should be part of the calculation the next time the question comes up.

A Practical Starting Point

If you are unsure whether automation is viable, start with a read-only reporting integration. It answers the question cheaply, it delivers immediate value - live outstanding balances, revenue by customer, aged debt without opening the accounting software - and it establishes what the data actually looks like before anyone commits to writing into it.

Any decision that changes how financial documents are created should be reviewed with your accountant before it goes live. This is a technical guide, not accounting advice.

To find out what is possible with your specific installation, book a free call. Related: what connects to what in the Israeli stack, automating invoices with the Morning API, and joining accounting data into a BI dashboard.