A CRM-to-invoicing connection breaks on duplicate customers and an undefined sync direction. What to connect, what to leave apart, and how to avoid two records.
Key takeaways
- First decide who is master for the customer - only then connect.
- One direction beats two. Two-way sync on the same field conflicts with itself.
- The matching key must be agreed: phone, email, or company number - never a name.
- What actually needs syncing is small: customer, documents, and payment status.
Connecting a CRM to invoicing software sounds like a technical project and is mostly a decision: who owns the customer record. Two systems managing customers without that decision produce two records for the same person, and then somebody sends an invoice to an old address or calls a customer who has already bought.
How do you connect Morning (Green Invoice), iCount or Rivhit to a CRM or a website?
Through each system's API, not a blanket sync: the CRM or website creates the client and asks the invoicing system to issue the document, which reports back its number, link and payment status. Morning and iCount can push events by webhook; Rivhit's documents API is polled. We build these connections; one workflow is priced at $300 - $1,800.
Morning, iCount and Rivhit: what each API gives a CRM
The three most common Israeli invoicing systems all have a documented API, but they differ in exactly the places a CRM connection depends on:
| Morning (Green Invoice) | iCount | Rivhit | |
|---|---|---|---|
| Style and auth | REST, OAuth client credentials, token valid for one hour | POST with JSON to /api/v3.php/ plus module and method, Bearer token with no expiry | WCF-style named operations, api_token in the request body |
| Issue a document | POST /documents | doc/create | Document.New |
| Push to the CRM | Webhooks set up in the interface: document/created, payment/received, client/created | Webhooks registered through the API with webhook/add | The documentation lists push notifications (IPN) for iCredit payments |
| Duplicate guard | Your own job key; error 1010 flags a request with identical data | sanity_string, up to 30 characters | request_reference with prevent_duplicates |
| Where the CRM's own id goes | Keep Morning's client id in the CRM; client search filters by name, email, contact person and labels | custom_client_id | acc_ref, up to 9 characters |
| Open balance for the customer card | /clients/{id}/balance | client/get_balance, client/get_open_docs | Customer.Balance, Customer.OpenDocuments |
For each system in depth: issuing documents through the Morning (Green Invoice) API, the iCount API v3 - authentication, doc/create and webhooks, and the Rivhit API - Document.New, duplicate prevention and iCredit.
Which flows are worth connecting first?
- Deal won in the CRM. The client is created or updated in the invoicing system and a proforma or tax invoice is issued (in Morning, type 300 or 305).
- Payment received. A receipt is issued against the invoice - in Morning,
linkedDocumentIdscloses the original - and the CRM marks the deal paid. - Website order paid. A tax invoice-receipt is issued (type 320 in Morning,
invrecin iCount) and its link is saved on the order. - Document back on the customer card. Number and link, so nobody logs into the invoicing system to find them.
- Open balance on the customer card. Read from the balance calls in the table, so a salesperson knows before calling.
What should you connect and what should stay apart?
| Data | Sync? | Recommended direction |
|---|---|---|
| Customer details | Yes | From CRM to invoicing, if customers are managed there |
| Issued documents | Yes | From invoicing to CRM, for viewing |
| Payment status | Yes | From invoicing to CRM |
| Quotes | Depends | Usually from wherever the sale is closed |
| Opportunities and leads | No | They have no business in an invoicing system |
| Correspondence and activity | No | Stays in the CRM |
| Items and prices | Sometimes | From whichever system owns the price list |
The fifth row is what businesses try to sync by mistake: a lead who has not bought is not a customer, and there is no reason for them to appear in a system that issues documents. It only inflates the list and makes searching harder.
Why it breaks: duplicates
The central problem in any such connection is the same customer existing twice. It happens because:
- The name is written differently in the two systems - with or without the company suffix, with or without punctuation.
- There is no agreed matching key, so matching falls back on the name.
- A customer was created manually in one system while the connection already existed.
- The same person has two emails - business and personal.
The fix is agreeing on one key and enforcing it: a mobile number is usually the good choice in Israel, because it is unique, stable and almost always present. Handling duplicates fully is covered in cleaning up messy data.
Webhook or polling: how does the CRM learn that an invoice was paid?
| Webhook | Polling | |
|---|---|---|
| How it works | The invoicing system calls your URL when an event happens | Your system asks on a schedule: POST /documents/search in Morning, doc/search in iCount, Document.List in Rivhit |
| Delay | Seconds | The polling interval |
| What it needs | A public HTTPS endpoint, a signature check, a fast answer and deduplication | A scheduler that respects limits - Rivhit allows 200 requests a minute, Morning search pages hold up to 100 results |
| How it fails | Quietly: Morning disables a webhook after 15 failed deliveries, iCredit resends a notification that got no 200 within 1.25 seconds | Visibly: a scheduled job that did not run |
The robust answer is both. Use the webhook for speed and a nightly polling pass as reconciliation: it compares the day's documents and payments with what the CRM holds and fixes the gaps a missed delivery left behind.
What breaks a CRM-invoicing connection in practice?
- A token cached forever. Morning's access token lasts one hour; a job that never refreshes it gets 401 halfway through a batch.
- A webhook that went quiet. After 15 failed deliveries Morning stops sending, and nothing in the CRM shows it.
- A payment processed twice. A slow listener makes iCredit resend the IPN, and a handler without deduplication books the payment twice.
- Truncated customer details. Rivhit limits
last_nameto 30 characters andacc_refto 9. - A client created twice. iCount's
doc/createcreates a new client when its lookup by id, tax id, email and name finds nothing. - A test document emailed to a real customer. Rivhit's
send_maildefaults to true. - The monthly document cap. Morning returns error 1112 once the account reaches its maximum for the month.
- VAT sent as 18. Morning expects a VAT rate between 0 and 1 and rejects anything else with error 1108.
The setup order
- Decide who is master for the customer. Usually the CRM, if sales start there.
- Choose a matching key and confirm it exists and is valid in both systems.
- Clean before connecting - duplicates, empty records, inconsistent phone formats.
- Connect one direction only at first, and watch it for a week.
- Add documents and payment status flowing back into the CRM.
- Define conflict behaviour - who wins when both sides changed.
Step three is the one people skip and the source of most problems. Importing a dirty list produces duplicates in the second system, and then you have two dirty lists instead of one. I build these end to end - see custom CRM development.
What you actually gain
- No double typing of customer details.
- A salesperson can see whether the customer paid without asking bookkeeping.
- A quote that became a deal turns into a document without starting over.
- One customer view covering both sales activity and payment history.
The second item is what changes the working day: a sales call to a customer who has not paid is an awkward call, and most salespeople simply do not know.
What not to expect
- Not every field will move. A commercial connector moves what it was built to move, not everything.
- Not in real time. Most connections run on a cycle, and that is fine.
- It will not fix an existing mess. A connection copies the current state, duplicates included.
- It will not replace a decision. If nobody knows who is master, the connection just spreads the confusion faster.
What to check in the first week after connecting
A new connection looks fine on day one and reveals itself broken in week two. Five checks worth running:
- Create a new customer in the master system and confirm they appear in the second with all fields.
- Change an existing customer's details and confirm the change carried across rather than creating a second record.
- Issue a document and confirm it appears on the customer record in the CRM.
- Mark an invoice paid and confirm payment status updated.
- Search for the same customer in both systems and confirm there is only one.
The fifth is the most important, and worth repeating after a month too - because duplicates appear gradually rather than all at once.
How to build it without a developer
Most small businesses need no development: many Israeli systems offer ready connectors or work through well-known automation platforms, and iCount for instance presents an app on an automation platform alongside its API. What you do have to do yourself is the decisions: who is master, what the key is, and what flows in which direction. Those are not technical questions and no developer will answer them for you - which is exactly why connections fail in businesses that have an excellent developer. For realistic build tiers and what moves a project between them, see how much a custom CRM costs.
When not to connect
Some situations add complexity without value: when the customer count is small and there is no meaningful double typing; when one person operates both systems and sees everything anyway; and when one of the systems is likely to be replaced within six months. In all three, waiting is better - a connection built and discarded is double work.
What happens when one of the systems is replaced
A connection built between two systems becomes a burden the moment one of them changes, so it is worth knowing in advance what will happen: whether the key you chose exists in the new system; whether the connection itself is transferable or must be rebuilt; and what happens to data created while it was running. Those three questions deserve a short conversation before replacing anything, because they decide whether the move takes a week or a month.
Sources
Frequently asked questions
Which system should be master?
Usually whichever creates the customer first - the CRM, if sales start there. In a business where most customers arrive through an online store, the invoicing system may be the master instead. What matters is that there is one written decision everybody knows.
Can I sync in both directions?
Technically yes, and practically it is a source of problems: when both sides can change the same field, you need a rule for every conflict. Usually it is better to run one direction for customer details and the reverse for information created in the other system - documents and payment status, for example.
What about duplicates that already exist?
Clean before connecting, not after. Merging a hundred records by hand is a day's work; merging a thousand after the connection duplicated them is a project. If the list is large, sort by phone number and work in groups.
Do I need a developer to connect them?
Not necessarily. Some Israeli systems offer ready connectors or work through well-known automation platforms, and that is enough for most businesses. A developer is needed when the logic is unusual - complex sync rules or an internal system.
Does Morning (Green Invoice) send webhooks to a CRM?
Yes. Webhooks are set up in the Morning interface under Developer Tools, and the events include document/created, payment/received and client/created. Each delivery can be signed with HMAC-SHA256 in the x-webhook-signature header. Answer with a 2xx status quickly, because after 15 failed deliveries Morning makes the webhook inactive.
Should a CRM use webhooks or polling to track invoice payments?
Both, for different jobs. A webhook updates the CRM within seconds but can fail quietly - Morning disables one after 15 failed deliveries. A nightly polling pass through each system's document search compares the day's documents with the CRM and fills any gap. Rivhit's documents API is polled in any case.
How does a CRM avoid duplicate documents in Morning, iCount or Rivhit?
Key every issue request on the CRM's own deal or order id. iCount refuses a second document with the same sanity_string, and Rivhit does the same when request_reference is sent with prevent_duplicates set to true. For Morning, keep a job record per order in your own database and check it before calling POST /documents.
Keep reading
Related service
Custom CRM
A CRM built around your pipeline, connected to the tools you already use.
Have 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.