How the accounting sync behaves

Sync runs on a schedule, not instantly. A change made in either system appears in the other on the next run, so a few minutes of disagreement is normal and not a fault. Most connections also allow a manual sync when you need something across immediately.

Not every accounting system is on a schedule yet. The newer connections are manual only: they sync when you press a button and at no other time. The Sync tab on the connection's settings page says which one you have, and how often the automatic run happens when there is one. If it tells you there is no automatic schedule, nothing is running in the background and the data is as current as your last manual sync.

Some systems tell us about changes as they happen. Tripletex sends each new invoice, order, payment, customer or product to DealJourney within moments, with no button pressed. On those connections each record type on the Sync tab shows two dates: when a sync last ran, and when the latest change arrived on its own. An old sync date next to a recent automatic change is normal: it means the automatic updates are doing the work. A sync only matters for older history that was never brought across.

"Last synced" and "Last checked" are different dates. Last synced is when records last came across. When a later run looked at your accounting system, for example one that found nothing new to bring, the Sync tab also shows a "Last checked" line with the date of that run. Every real run counts, automatic or by hand, whatever it found. Opening a preview does not count, because a preview only looks. So an old sync date beside a recent check means we have kept looking, not that work has been waiting since that date.

Your preview survives a settings-tab switch. After opening an accounting sync preview, you can check another settings tab and return to the same record type and direction. Selected records and their sync results stay available while the integration page remains open. Opening the integration page alone does not fetch a preview; open the sync tab when you need it.

Some records are read-only in the CRM on purpose. Skrivebeskyttet (betalt/kansellert) A posted or paid invoice belongs to the accounting system, and letting it be edited here would mean the two disagree about something that has legal and tax consequences. Where an action has to finish on the accounting side, DealJourney says so (Fakturautkast opprettet i Fiken, venter på bekreftelse) rather than pretending it completed.

Failures are recorded rather than announced. A sync that cannot map a customer or is rejected by the accounting system logs the problem and moves on. This is deliberate (one bad record should not stop the rest), but it means nobody finds out unless somebody looks. Check the sync activity log after any change to the setup, and periodically otherwise.

An invoice that only partly reached the accounting system is picked up again. An invoice is sent as a header and then its lines, so a product the accounting system refuses can leave a draft there with lines missing, billing the wrong amount. DealJourney keeps that invoice marked as not finished, shows it on the connection's settings page with the reason it was refused, and tries again on its own a few times, adding only the lines that are missing. It never creates a second invoice for the same sale. If the draft was edited on the accounting side, or has already been posted there, nothing is sent and the page tells you to correct it there instead.

You choose which system wins a disagreement. The connection settings hold a winner per record type (customers, contacts, products) plus whether a disagreement should be resolved automatically or left for a person. It only comes up when both sides changed the same record since the last sync; a change on one side alone is simply carried across.

With the accounting system set as the winner, its values replace yours. With DealJourney set as the winner, a record you have edited here since the last sync is kept and reported as skipped, and the incoming values are dropped. Your edit survives every later sync too, not just the next one. Choosing to resolve disagreements by hand keeps both versions and writes neither.

Duplicates come from matching on names. If the same customer exists on both sides having been created independently, the sync only recognises them as one another if it can match on something stable. Fixing the match rule stops new duplicates; the existing ones need merging.

A missing customer usually failed validation. Accounting systems demand fields a CRM does not (a registration number, a country, a payment term), and a customer without them is rejected rather than created. The log names which field.