Which currencies does HubSpot invoice sync support?

Six, according to HubSpot's documentation: USD, CAD, EUR, GBP, AUD and NZD. This is a hard boundary rather than a configuration problem. If you bill in any other currency, the native route does not cover that revenue and no amount of field mapping will change it.

Does HubSpot's Persistent Customer Mapping fix the duplicates?

Partly, and not yet for everyone. Persistent Customer Mapping matches on stable record IDs rather than email. As at September 2026 it entered private beta in July 2026, is limited to Revenue Hub Professional and Commerce Hub, and is outbound only. Invoices arriving from the accounting system still match on email, and no remediation timeline for that inbound path has been published.

Can invoices created in HubSpot be edited in Xero?

No. HubSpot's documentation is explicit that invoices created in HubSpot must be edited in HubSpot, and that editing them in Xero causes sync failures. Nothing blocks the edit at the moment it is made, so this has to be handled as a written process rule for the finance team rather than as a technical control.

Should we use the native app, an iPaaS, or a data warehouse?

The native app is fastest and supported, but its documented constraints cannot be extended. An iPaaS gives you custom matching and branching, at the cost of task-volume pricing that makes retry storms expensive as well as duplicative, and multi-step scenarios that are hard to troubleshoot. ELT into a warehouse is resilient to API outages and gives you reporting neither system can produce, but it needs data engineering and it is a reporting route, not a writeback route.

HubSpot to Xero: what breaks after 13 March 2026

What changed in 2026?

Xero's notice was unambiguous: "The integration will be automatically disconnected [...] from 13 March 2026." That is what pushed many teams onto other routes, and the kind of event it was matters. Not a settings change or a version upgrade — the connector was withdrawn, so every team using it had to choose a replacement architecture on someone else's timetable. The same forced-migration shape as the Relay.app shutdown, with the same consequence: decisions made under time pressure become the permanent configuration.

What does not sync, and what does that cost you?

This is the most useful thing on the page, so it goes early. Every row is drawn from HubSpot's own documentation — the vendor describing its own product's limits, which is the safest source available.

Constraint	What HubSpot documents	Practical consequence
Currency	Six supported: USD, CAD, EUR, GBP, AUD, NZD	A hard boundary, not a mapping problem. Revenue billed in any other currency is outside the native route.
Tax rates	"Tax rates created in HubSpot won't sync to Xero"; multi-tenant Xero accounts are not supported for tax imports	Tax must be authored in Xero and imported. Agencies and groups on multi-tenant Xero fall outside the supported path.
Edit location	Invoices created in HubSpot must be edited there; editing in Xero causes sync failures	A process constraint on your finance team, enforced by nothing.
Draft invoices	Do not sync	Anything in draft is invisible on the other side. Pipeline figures built on drafts will not agree with the ledger.
Credit card fees	Do not sync	The two systems disagree on what was collected. Someone reconciles the difference by hand, every month.
Prerequisite records	Contacts and products must already exist in both systems before invoice sync works	The sync does not create the counterparty. A new customer fails until seeded on both sides.
Payment history	Only payments created after the connection syncs — explicitly, to avoid duplicates	Everything before cutover is a migration you own. Plan it; it will not arrive on its own.

Read that as a specification rather than a list of complaints. Most are defensible design decisions — the payment cut-off exists precisely to prevent the duplicate problem discussed next. The failure is not that the constraints exist. It is that they are discovered by an accountant in month three.

Why do duplicate customer records keep appearing?

This one deserves its own section because it is subtle, silent and structural. It is not a bug anyone can point at.

Customer matching has historically been performed on email address, and email addresses are mutable. When a contact's email changes — a rebrand, a name change, someone moving from a shared info@ mailbox to their own — the matcher no longer finds the existing customer and creates a new one. An audited case documented by Sidekick Strategies records exactly this: "a contact email update created three duplicate customer records in QBO". That was QuickBooks Online, but the defect lies in the choice of matching key rather than in the ledger, so the same shape applies to Xero.

Nothing errors. Both systems behave correctly by their own rules. The damage surfaces later as a customer whose ageing is split three ways, statements that do not reconcile, and a credit limit that means nothing because it is enforced against one record of three.

Does Persistent Customer Mapping fix it?

It is a real fix, and it does not yet close the loop. HubSpot shipped Persistent Customer Mapping, which matches on stable record IDs rather than email. Stated precisely, as at September 2026: private beta from July 2026, limited to Revenue Hub Professional and Commerce Hub, and outbound only. Invoices arriving from the accounting system still match on email, and no remediation timeline for that inbound path has been published.

So if you run bidirectional sync — most teams do — half the surface still matches on a mutable key. Plan for that rather than assuming the announcement covered you.

Why must an invoice be edited where it was created?

Because the coupling is operational, not technical. Xero will happily let a bookkeeper amend an invoice that originated in HubSpot, and nothing warns them. The sync then fails days later, as an error in an integration log nobody has been assigned to read.

That makes it a policy problem. Somebody has to tell the finance team, in writing, which system is authoritative for which invoices, and somebody has to own the error queue. A constraint that manifests as a delayed, silent failure is among the harder things to govern, because the person who caused it gets no feedback at all.

What else drifts once invoices flow both ways?

Three further issues come from IntegrateIQ, an integration vendor — weight them accordingly, noting that their claims on currency limits and multi-tenant support are corroborated by HubSpot's own documentation. They report that invoices synced from Xero are not automatically linked to the originating deal, breaking deal-level revenue reporting; that per-line-item tax codes and discount tiers do not map cleanly; and that payment status carries roughly a 30-minute polling delay. The last is harmless for reporting and genuinely awkward for anything that gates fulfilment on payment.

Which route should you actually choose?

Fivetran's framing of three standard approaches is a sound way to think about it, and the honest comparison looks like this.

Route	Genuinely good at	What it costs you
Native app	Fastest to stand up, supported by both vendors, no third party in the data path	The constraints above are non-negotiable. You cannot extend it.
iPaaS (Zapier, Make, Workato)	Custom matching, field mapping and branching — it covers what the native route will not	Task-volume pricing, so a retry storm costs money as well as creating duplicates. Multi-step scenarios are hard to troubleshoot when the real fault is three steps upstream.
ELT via a warehouse	Resilient to API outages, full history retained, reporting neither system can produce alone	Needs data engineering. It is a reporting route, not a writeback route.

Two governance notes if the iPaaS route is in play. Both Zapier and Workato are cloud-only; Zapier staff have confirmed this on their official community. Workato's On-Prem Agent is frequently misread as on-premises deployment — it is not. It "create[s] a secure connection from within your private IT environment to connect to Workato cloud" over an outbound TLS WebSocket, while orchestration and processing remain in Workato's cloud; data residency is US and EU (Frankfurt). Against that, Zapier's governance features include a queryable execution audit trail (Asset History), log streaming to Datadog and Splunk, role-based access control and action restrictions — a serious list. Evaluate on what a platform does as well as where it runs, and be honest about which of the two your obligations actually turn on.

When does a duplicate invoice stop being an embarrassment?

When it lands in a jurisdiction with continuous transaction controls. At that point a sync error is no longer an internal tidying job; it is a tax event.

In Poland, an invoice accepted by KSeF receives a numer KSeF and cannot be deleted — only corrected. A duplicate is not withdrawn but corrected by a further document, and penalties under art. 106ni apply from 1 January 2027 at up to 100% of the VAT amount. That is the duplicate problem above, transposed into a clearance regime where the mistake is permanent; the mechanics are covered in idempotencja w KSeF. In France, where the reform went live on 1 September 2026, the lifecycle statuses Rejetée (technical rejection) and Refusée (commercial refusal) are legally distinct — so a connector auto-mapping internal error codes onto them is emitting legal characterisations on your behalf, as set out in the 2026 reform analysis. In Kenya, from the 2026 tax year the KRA validates income and expenses in income tax returns against eTIMS and TIMS invoices, and the transitional relief ended on 30 June 2026; see eTIMS return validation.

Duplicate invoices in a spreadsheet are embarrassing. Duplicate invoices in a national clearance system are a correction filing.

What should you instrument, whichever route you take?

Three things, none of which any of the routes gives you by default.

An idempotency key assigned before the first attempt. Not derived from mutable content and not generated on retry — generated once, when the business event occurs, and carried through every attempt. It is what makes a retry safe rather than duplicative: the difference between a timeout and a second invoice.
Reconciliation in both directions. Count invoices, customers and payments on each side and compare. One-way checks find missing records; only two-way checks find orphans — the record sitting in Xero with no HubSpot counterpart, which is exactly what a failed edit leaves behind.
A record of what was sent, when, and with what result, that outlives the platform. Integration logs are retained for the vendor's convenience, not for your obligation, and they leave with the subscription. If a tax authority asks in 2029 what you transmitted in 2026, the answer has to live somewhere you control.

Frequently asked questions

Did Xero remove its HubSpot integration?

Yes. Xero's notice stated it would be automatically disconnected from 13 March 2026, which forced a route change rather than a settings change.

Which currencies are supported?

Six, per HubSpot's documentation: USD, CAD, EUR, GBP, AUD and NZD. Other billing currencies are outside the native route.

Why do duplicate customers appear?

Matching on email address, which is mutable. Sidekick Strategies documents a single email update producing three duplicate customer records in QuickBooks Online; the same matching-key failure applies to Xero.

Does Persistent Customer Mapping solve it?

Only partly. Private beta from July 2026, Revenue Hub Professional and Commerce Hub only, and outbound only — inbound invoices still match on email, with no published remediation timeline.

Can we edit HubSpot invoices in Xero?

No. HubSpot documents that this causes sync failures. Nothing blocks the edit, so it has to be a written rule for the finance team.

Native, iPaaS or warehouse?

Native for speed within its limits; iPaaS for custom matching, accepting task-volume pricing and harder troubleshooting; ELT for resilient reporting, accepting that it does not write back.

BarzelOps is built for this shape of problem: cross-system workflow automation with durable state on PostgreSQL, crash recovery and idempotency keys assigned before the first attempt, human approval checkpoints with resumable execution, and signed evidence receipts that record what was transmitted, when and with what result — independently of any single vendor's retention policy. It is not a HubSpot–Xero connector and does not replace one; it is the layer that makes a connector's failures visible and its retries safe.

In practice

Automation you can leave, with the approvals and the evidence intact.

A workflow platform is only as safe as your ability to leave it. BarzelOps runs cross-system workflows with durable state, human checkpoints and signed evidence, exports them as a portable manifest, and migrates Relay workflows with a dry run before cutover.

Xero retired its HubSpot integration on 13 March 2026

BarzelOps

Governed workflow automation across the systems that run the business.

Durable, idempotent execution: a timeout is retried once, never filed twice.
Human approval checkpoints that pause the workflow and resume it.
Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.

Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize

Start free Ask by email Product page Documentation

BarzelVault

The AI action firewall: decide what an agent may do before it does it.

Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
Credential isolation, spend and action limits, and an emergency kill switch.

Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize