Two systems with different ideas of a customer
HubSpot thinks in companies, contacts and deals, shaped around winning work. Exact thinks in relations and accounts, shaped around invoicing it. Both are correct about their own half, and neither has a concept that maps cleanly onto the other. Every integration between them is really an argument about identity, and the sooner that argument is settled explicitly the less of it you resolve by hand later.
Pick one key, and let it be the only key
Matching on company name feels natural and fails immediately, because the same organisation is written four ways across two systems and neither is wrong. Use the VAT or company registration number: it is unique, both systems can hold it, and it is the same identifier the customer uses about themselves. Store the counterpart record id on both sides once matched, and match on the stored id from then on. The name becomes something you display, never something you join on.
Ownership per field, not per record
The instinct is to decide which system is the master. The useful version is finer than that: decide per field. Lifecycle stage, owner and pipeline belong to HubSpot and should never be written from outside it. Invoice status, payment terms and outstanding balance belong to Exact and should never be edited in HubSpot. Address and VAT number need one nominated owner, and the decision matters less than writing it down. A field with two owners is a field that will flap between two values on a schedule nobody remembers configuring.
One direction wherever one direction will do
Two-way sync is the default request and rarely the right answer. Financial records flowing from Exact into HubSpot so sales can see payment status is one direction and solves most of the actual need. Making it two-way so someone can edit an invoice from a CRM card adds conflict resolution, an audit problem, and a new way for the ledger to be wrong. Build the direction that is asked for, not the symmetrical version that sounds more complete.
Design for partial failure, because you will get it
The integration will be halfway through a batch when a token expires, a rate limit hits, or Exact returns a validation error on one record in fifty. Every write needs to be safe to repeat, which means keying on the counterpart id rather than creating on every run, and every failure needs to leave enough behind to resume from. A sync that can only be run from the beginning is a sync that stops being run.
What not to sync
The temptation is to mirror everything on the grounds that it might be useful. Resist it: every synced field is a field that can now be wrong in two places, and most of them are never read. Sync what someone has said out loud they need to see. Individual invoice lines almost never qualify; an outstanding balance and a payment status usually do.
What it buys
A salesperson who can see, on the company record, that this customer has an invoice ninety days overdue before offering them an upsell. Finance that stops being asked for that information over chat. And one place where the question of whether a customer is worth chasing has both halves of the answer in it. That is the whole return, and it is enough.