What should I ask before quoting a Hashavshevet integration?

Three questions, in writing: which programmatic interface is available in the exact version and edition installed; whether an additional module or licence is required; and the vendor's position on direct database reads. If a paid module is needed, that is a purchasing decision to escalate rather than a technical problem to route around in code.

Can I write directly to the Hashavshevet database?

No. An accounting application maintains sequential-numbering counters, audit structures and associated entries that direct writes bypass, producing books that look correct and are not. That is an accounting problem rather than a bug you can fix later. Reading for reporting with a dedicated read-only user is a different matter and is usually acceptable - but confirm it with the vendor first.

What is the simplest way to get data out of Hashavshevet?

A scheduled export to a file. It is unglamorous, survives version upgrades and requires nothing from the vendor, and it covers most real requirements - daily reports, customer balances for BI, transaction lists. Process the exported file as raw text rather than opening it in Excel, which silently flips dates and strips leading zeros from phone and registration numbers.

Hashavshevet Integration Guide

Q: Does Hashavshevet have an API?

There is no single answer, which is the important point. Hashavshevet originates in the desktop world, so the available interface depends on the version, the edition, whether it is installed locally or hosted, and sometimes on an additional purchased module. Establish in writing what the specific installation has before pricing any integration.

Hashavshevet comes from the desktop world, so the first question is not how to call an API but whether a suitable interface exists in your specific installation. The questions to ask, the fallbacks that work, and why you must not quote before you know.

Hashavshevet is one of the long-established and widely used accounting systems in Israel, and when the need arises to connect it to something - a store, a CRM, an internal system - the question asked is "what is its API". That is the wrong question, and it is why such projects get priced wrong.

This guide presents no request shape, deliberately. I do not publish an endpoint I have not verified, and in a system originating in the desktop world - where the interface depends on version, edition and how it was installed - any specification I wrote would be right for one installation and wrong for another. Instead, here is what does help: what to establish, and how to plan.

Why this differs from a cloud system

A cloud invoicing system - Morning, iCount, EZcount, Rivhit - is one service with one interface. There is an address, there is documentation, and every customer gets the same thing.

Hashavshevet comes from a different world. Which means:

The version matters. What exists in a current edition does not necessarily exist in an installation that has been running for five years.
The edition matters. Integration capabilities are often sold within a particular edition or as an add-on.
How it is installed matters. A local install on the client's server differs from a hosted one.
Who maintains it matters. There is usually a Hashavshevet person - a reseller or implementer - who knows things written down nowhere.

The conclusion: "does Hashavshevet have an API" is a question with no single answer. The right question is "what does this installation have".

Three questions to ask - in writing

Before any estimate, to the vendor or to the client's Hashavshevet person:

"Which programmatic interface is available in the version and edition we have installed?" - state the exact numbers. A general answer is worth nothing.
"Does it require purchasing a module or an additional licence?" - if so, that is a purchasing decision, not a technical problem. Raise it with whoever controls budget immediately rather than trying to route around it in code.
"What is your position on reading directly from the database?" - better asked up front than discovered a year later to void support.

In writing, because in a year someone will ask why it was built this way.

Do not price before you have answers. The gap between "there is a programmatic interface" and "there is not" is not a percentage - it is the gap between a week-long project and an entirely different one.

If there is no suitable interface - what does work

In most cases one of these meets the actual requirement. Detailed in my software has no API, and briefly here in the Hashavshevet context:

Scheduled export - the answer in most cases

The system can export. You pick up the file and process it.

It is boring, it survives upgrades, and it requires nothing from the vendor. If the need is "a daily report", "customer balances for BI" or "a transaction list" - and that is most cases - this is the answer and you are done.

What to watch: an export file is a spreadsheet, so it has no types. Dates flip, the leading zero on a phone number disappears, and company registration numbers lose leading digits. Process the file as raw text rather than opening it in Excel on the way.

Direct database reads - for reporting only

If the system runs on an accessible database, reading for reporting and BI is usually acceptable. Preferably with a dedicated read-only user.

Direct writes - no. And in an accounting system this is graver than anywhere else: it maintains sequential-numbering counters, audit structures and associated entries. Direct writes bypass them and produce books that look correct and are not. That is not a bug you fix - it is an accounting problem.

Additionally: a closed system's schema is not a contract. An upgrade can change names and meanings without notice, because to the vendor it is internal.

A shared folder

Established systems can drop a file into a folder or pick one up. It looks archaic and works well. What must be in place: a marker file signalling the write finished, moving to an archive after processing, and idempotency.

UI automation - last resort

A script driving the software like a user. It works, and it breaks on any interface change - silently. Do not run it unattended on financial operations. A script entering accounting transactions without oversight is a risk not worth the saving.

What stays true regardless

These apply to every option, and they are the difference between an integration that holds and one that falls apart:

Idempotency. The same transaction processed twice produces one result. In accounting a duplicate is not an inconvenience, it is an incorrect entry.
An error queue a human sees. A failed record must appear somewhere someone checks each morning.
A daily reconciliation job. Compare totals across both sides - not row counts. An identical row count with a different total means something did not transfer correctly.
Document the assumptions. File structure, field names, the version it was built against. When it breaks, whoever fixes it needs to know what was assumed.

The decisions that are not technical

Even with a perfect interface, these remain - and they are the real cost:

Who decides what is recorded and when. That is the accountant's decision, not the developer's. If your system produces accounting entries, the logic needs written sign-off.
What happens with an incorrect entry. In accounting you do not delete - you correct with an offsetting entry. The code has to know that in advance.
VAT. Verify against a real document how the system expects amounts. Five minutes that prevent a month-long correction.

Practical summary

Establish in writing what exists in the specific installation - before pricing.
If a paid module is required, raise it as a purchasing decision rather than routing around it.
If there is no interface, a scheduled export solves most cases.
Database reads for reporting: maybe. Writes: no.
Get written confirmation from the accountant on what is recorded and when.
Build idempotency and reconciliation from the start.

Automating Hashavshevet: What to Establish Before You Promise Anything

Key takeaways