CRM to invoicing sync: stop typing everything twice

What exactly crosses between the systems, and in which direction?

A working connection is not everything syncing in all directions. It is four defined routes, and each one has a single direction. One direction per field is what prevents a conflict that cannot be resolved automatically.

• Customer. Created once, in the system named as the owner of customer details, and mirrored to the other under the same name and the same identifying number. The registered name, the business number and the billing address are the fields that must match exactly, because those are the ones that appear on the document.
• Quote. Built in the CRM, where it belongs to the sales process. Once approved, it becomes a document in the invoicing system without anyone retyping the lines.
• Invoice. Issued only in the invoicing system, never in two places. The document number and a link to it return to the customer record in the CRM, so the salesperson sees them without opening another system.
• Payment. Received in the invoicing system and updates the status in the CRM. This is the field most of these connections are built for: it ends the "has he paid yet?" question that gets asked out loud several times a day.

The three failure points that break the connection

Connections like this almost never fail on infrastructure. They fail on three places that look minor during setup and expensive afterwards, and all three are checked before anything is built rather than after.

• The duplicate customer. The same customer already exists in both systems under two different spellings: with and without the company number, with and without the legal suffix, in Hebrew and in English. A connection that matches on name will open a third record. Matching has to run on the business or company number, and whatever is not matched with certainty goes onto a list a person settles once, before go-live.
• Document numbering. Numbering series are an accounting requirement, not a preference. A connection that issues a document outside the series, or leaves a gap between numbers, creates a problem that surfaces in an audit rather than on the day it was made. The invoicing system is always the one that issues the document, and the configuration is agreed with the bookkeeper.
• Credit notes and refunds. This is the part most connections simply skip. A credit note is not a negative invoice: it is a separate document that must point at the original, and it changes both the balance and the reporting. A connection that never handled credit notes will look correct until the first one, and will then quietly pull the two systems apart.

How long does setup take, and what is needed from you?

Setup time comes almost entirely from the state of the data rather than the volume of documents. A connection across two clean, agreed systems is short work. The same connection across a customer base grown over seven years with no naming rules is mostly cleaning, and the connection itself is the small part.

What is needed from you: read and write permissions to both systems at the scope the process requires and no wider, a decision on who owns customer details, and the bookkeeper's approval of the numbering series. The measurement stage ends with a numeric answer about your process: how many documents a month, how many are touched by hand today, and how much of that remains after the connection.

Which similar connections do we build?

The same principle repeats for any pair of systems, and what changes is what each side allows. The typical Israeli environment is built from a finance system such as Hashavshevet, a core system such as Priority, invoicing in Green Invoice, work management in Monday, and files in Microsoft 365.

Testing the connection against the system itself, in the version and with the permissions you hold rather than by what the documentation claims, is part of the measurement stage. Promising an integration in a sales call without opening the system is the fastest route to a project that stalls halfway. More on working against existing systems is on the business process automation services page, and on the finance side in finance automation.

When we say no

Connecting systems is not always the answer, and there are cases where it only locks an existing problem in place. These are the cases where we will tell you no, even when you are asking for yes:

• When nobody has decided who owns customer details. That is not a technical problem but a disagreement about who holds the correct record. A connection will only make the disagreement faster.
• When the database is not clean. If the same customer exists under three spellings, the connection will duplicate the mess across two systems instead of one. Clean first, connect second.
• When the volume is small. A business issuing a handful of documents a month will not recover the setup and maintenance cost. A minute of typing, a few times a month, is not a problem that needs software.
• When you are mid-replacement of either system. Building a connection to the system on its way out is waste. You wait.

Some measurements end in the conclusion that the saving does not justify the investment, and that is a legitimate answer. A supplier who agrees to every request has already decided what they are selling you, before seeing what you have.