A practical fit test: list the workflows your business runs, then check what Priority, Hashavshevet and Rivhit publicly document for each one. No pricing.
Key takeaways
- Company size predicts user count, not the shape of the work. Two businesses with eight employees can need completely different systems.
- Rivhit publishes a public help page that lists its operations by name, including Document.InvoiceApproval, described as "Acquire confirmation number for given document".
- Priority publishes a public developer portal with a generic OData interface over system forms, demonstrated on the ORDERS and ORDERITEMS entities.
- No public developer documentation site was located for Hashavshevet when checked in September 2026. That is a statement about documentation access, not about whether a capability exists.
- "Not found in public documentation" belongs on the list of questions for the vendor, not on a list of reasons to reject a system.
The choice between Priority, Hashavshevet and Rivhit is decided by the list of workflows a business actually runs, not by headcount. Write down your ten workflows, then check what each vendor's public interface documents for each one. Whatever is not documented becomes a question for the vendor, not an assumption.
Why is company size the wrong axis?
Because it measures licence count, not the number of states your process has to represent. A three-person warehouse handling serial-numbered items, delivery on installation and per-unit warranty produces more states than a forty-person services firm issuing one fixed monthly invoice.
The right axis is the workflow list. A workflow is a sequence that starts with an event and ends with a document or a posting: order in, pick, ship, invoice, collect. Any workflow the system cannot represent ends up back in a spreadsheet, with a person keying it twice.
The ten workflows worth writing down before you talk to a vendor
- Issuing sales documents: quote, order, delivery note, invoice.
- Obtaining an invoice allocation number from the Tax Authority.
- Exporting the uniform-format file for your accountant or an audit.
- Managing stock in more than one warehouse, including transfers between them.
- Different price lists for different customers.
- Journal entries and bookkeeping reports.
- An appointment or booking diary tied to a customer.
- A physical till and point-of-sale selling.
- Manufacturing: bill of materials, work order, production reporting.
- Free reading of any table in the system for a report or a control check.
That list is the input. The table below is what can be verified against it from outside.
What each system's public interface actually documents
| Workflow | Priority | Hashavshevet | Rivhit |
|---|---|---|---|
| Sales documents | Reachable through a generic OData interface over forms; the documentation demonstrates ORDERS and ORDERITEMS | No public developer documentation located | Operations named Document.New, Document.NewExtended, Document.NewStream |
| Invoice allocation number | No dedicated endpoint located in the public REST documentation | No public developer documentation located | Document.InvoiceApproval, described as "Acquire confirmation number for given document" |
| Uniform-format export | Not located in the public REST documentation | No public developer documentation located | OpenFormat.ZIP, described as "Create an open format files zip" |
| Multiple warehouses | Reachable through generic OData, subject to which forms are configured | No public developer documentation located | Storage.List, Storage.New, Item.StorageReport |
| Price lists | Reachable through generic OData | No public developer documentation located | PriceList.List, PriceList.Items |
| Bookkeeping | Reachable through generic OData | No public developer documentation located | Accounting.AddJournal, Accounting.JournalsReport, Accounting.VatReport |
| Appointment diary | Not located in the public REST documentation | No public developer documentation located | Appointment.New, Appointment.List, Appointment.Update |
| Point of sale | Not located in the public REST documentation | No public developer documentation located | POS.Document, POS.Receipt, POS.GetSession |
| Manufacturing and BOM | Reachable through generic OData where the forms exist under the licence | No public developer documentation located | No operation whose name refers to production, a bill of materials or a work order appears in the published list |
| Free reading of any table | Yes: documented operators $filter, $select, $expand, $top, $skip, $orderby | No public developer documentation located | No. The interface is built from named operations, not from a free query |
That last row is the most important structural difference in the table, and it is worth reading slowly.
Free query or named operations: which one fits your reporting?
Priority exposes an OData interface over the system's forms, which means whatever is configured in a form is readable with standard operators. In practice a report nobody anticipated is usually a query, not a project.
Rivhit exposes a list of named operations. Whatever has a name has an immediate and precise answer. Whatever has no name has no simple route, and you have to ask the vendor whether an additional interface exists that is not on the public help page.
For Hashavshevet, no public developer documentation site was located. That is not a claim that no interface exists, and the existing piece here on automating Hashavshevet and Rivhit explains why the answer there depends on the specific version and installation. It does mean a project estimate cannot start from reading. It can only start from a conversation.
Where this test usually goes wrong
The most common mistake is testing the workflows that are visible rather than the ones that hurt. The visible workflow is the one the owner describes in the first meeting: an order arrives and an invoice goes out. The expensive workflow is the one nobody mentions because a person absorbs it: the partial delivery, the credit note against two different invoices, the item that goes out for repair and comes back under a different serial number.
Three failure patterns show up again and again:
- Testing the happy path only. Every system handles the clean order. The differences appear on returns, partial shipments and corrections.
- Confusing a screen with an interface. A feature that exists in the user interface is not automatically reachable from outside it. That gap is exactly what the documentation check measures.
- Letting one impressive demo settle the list. A demo is a rehearsed path through the happy case. The workflow list is yours, so run the demo against your list rather than watching theirs.
Write the exception next to each workflow before you compare anything. If a workflow has no exception, it is probably not described accurately yet.
How to run the fit test yourself
- Write your ten workflows, one sentence each, from opening event to closing document.
- Mark who performs each one today and in which tool, spreadsheets included.
- Count how many times per week each one runs. A workflow that runs twice a year is not a selection criterion.
- Open each vendor's public documentation and search for the workflow by name. Record "documented" or "not found".
- Turn every "not found" into a written question to the vendor, with a concrete example from the business.
- Only then compare proposals. The comparison is shorter when both sides know exactly what is being measured.
What moves cost, when you are not discussing price
- The number of undocumented workflows. Each one is a schedule risk, because it starts with an enquiry rather than with development.
- How many fields cross systems. A field written in two systems forces an ownership decision, and that always costs more than the code.
- The number of exceptions inside each workflow. One exception on an order is a condition. Seven exceptions are a decision engine, which is a different category of work.
- How often it runs. A daily workflow justifies full automation; a quarterly one usually justifies a written procedure instead.
- Who maintains it after go-live. A system nobody can change a field in is a system that will freeze.
Related: integrating with the Rivhit API, integrating with the Priority API, the Israeli business software stack.
Sources
Frequently asked questions
Does "not found in public documentation" mean the capability is missing?
No. It means that reading the public documentation in September 2026 turned up no explicit confirmation. Many vendors publish fuller documentation only after an account is opened or an agreement is signed. The item moves to the list of questions for the vendor, not to a list of the system's shortcomings.
How many workflows should I list for the test to be useful?
Between eight and twelve. Fewer misses the rare workflows that generate the expensive exceptions. More turns the list into a task backlog rather than a decision tool, and in practice nobody honestly compares twenty rows in a single table.
Can I start small and move to a bigger system later?
You can, and the move costs mainly in data alignment rather than licensing. What decides it is how much history you must carry across and how many external identifiers are already stored in other systems. Plan the migration during the first selection, not two years after it.
What if the preferred system has no interface for a critical workflow?
Check whether that workflow can live in a separate layer that reads from the system and writes back only the result. That is usually far smaller work than replacing the system, and it stays under your ownership. If even reading is impossible, that is a real reason to consider a different system.
Keep reading
Related service
Custom Business Software
The internal system that replaces the spreadsheet you outgrew.
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. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.