Accounting
SalesPro Hub exposes the customer, submitted-order, inventory and signed-webhook building blocks needed for a custom Xero connection. Your connector must still authenticate with Xero, map contacts and accounting documents, and choose tax and stock policies. SalesPro Hub does not currently claim a native Xero OAuth connector or automatic invoice posting.
Test the field workflow firstSupport level: Custom API connection — Xero OAuth client required. The workflow below separates shipped SalesPro Hub capabilities from connector work your implementation must provide.
What this solves
A typical integration keeps field capture fast and offline-capable while using Xero as the accounting system. Submitted orders are transformed only after validation, and the resulting Xero document number is written back as the external reference for office and field teams.
Xero integration evidence
A useful Xero connection needs stable identities, explicit ownership and a visible exception path. These are the SalesPro Hub records the implementation must map and reconcile.
Written and maintained by Paul · Updated 28 July 2026
The connector should read submitted orders, validate the commercial mapping and create the accounting document selected by finance policy.
Consent, tenant selection, token refresh, revocation and reconnect behaviour belong in the implementation and support runbook.
Contact identity, ItemCode, quantities, discounts, tax types, accounts and approval status must be validated rather than inferred.
Automatic posting should follow the buyer’s approved tax, account-code, date, due-date and draft-versus-authorised policy.
A stable field order identity and stored external result prevent a lost response from becoming a second accounting document.
Compare counts, amounts, tax, customer identity, document references and rejected records before expanding the integration scope.
Architecture and ownership
A custom Xero connection normally runs as cloud middleware: the buyer authorises the intended Xero organisation, the connector maintains OAuth tokens, and submitted SalesPro Hub orders are transformed into the accounting document approved by finance. The returned Xero identifier and document number are written back so the office and field teams can refer to the same transaction. This design remains custom until consent, token lifecycle and entity mapping are packaged as a supported product adapter.
Xero owns the accounting document, contact identity, account code, TaxType, approval status and official accounting number.
SalesPro Hub owns field order capture, draft state, the source order number and operational fulfilment context.
The implementation chooses whether Xero contacts or SalesPro Hub customers are authoritative for each mutable field.
Stock ownership must be explicit because an accounting item quantity and a warehouse available-to-sell quantity may not mean the same thing.
OAuth consent must bind the intended Xero organisation and store access and rotating refresh tokens in encrypted server-side storage. Token refresh needs a concurrency lock so two workers do not invalidate each other’s rotated credentials. Scopes should match the selected accounting and contact operations. Logs and support screens must never expose access tokens, refresh tokens or full sensitive payloads.
Failure recovery
A useful Xero integration is not defined by one successful demo. It is defined by what remains durable, what can be replayed safely, what must stop, who sees the exception and how both systems are reconciled.
| Failure or conflict | Required response |
|---|---|
| Expired access token | Refresh once under a lock, persist the rotated refresh token and replay the same idempotent operation. |
| Contact or ItemCode missing | Stop the document before posting and expose the mapping exception for finance or master-data correction. |
| Validation error | Treat invalid TaxType, account, amount or status as a permanent business error, not an endless temporary retry. |
| Lost create response | Reconcile by idempotency key and source reference before considering another document request. |
| Wrong Xero organisation selected | Fail the tenant binding and require an explicit reconnect; never silently switch accounting organisations. |
Acceptance plan
A sandbox proves API syntax. Production readiness requires representative identities, accounting or CRM rules, failures and reconciliation. Record the result against the exact product edition and adapter release; do not transfer evidence from a different vendor version by assumption.
Delivery lifecycle
Treat the connection as a small operational product with owners, release evidence and a lifecycle. These phases stop a promising prototype from becoming an invisible production dependency that only one developer understands.
Name the exact Xero product, edition, company or tenant, licensed interface and deployment. Follow one representative customer and order from field capture to its final external state. Record current manual checks, approval points, cut-off times, volumes and the people who resolve errors. Brand-level assumptions are not a technical scope.
List required and optional fields, types, formats, allowed values and stable identities. Declare a source of truth for customers, outlets, products, prices, tax, stock, documents and status. Define create, update, deactivate and delete behaviour separately. Include the idempotency key, cursor or event identity and the external reference returned after a successful commit.
Classify authentication, rate-limit, connectivity, validation, mapping, conflict and external-service errors. Decide which faults retry, how often and with what backoff; which stop immediately; and where exhausted work becomes visible. Assign a named business or technical owner and define the evidence needed to replay, correct, reject or manually reconcile an operation.
Use representative South African customers, addresses, SKUs, rand values, VAT rules, discounts, warehouses and approval cases. Include duplicates, missing mappings, offline or network loss, service restart, expired credentials and a lost response after external commit. Reconcile counts and commercial totals in both systems; a green API response alone is not acceptance.
Version the mapping, adapter and configuration together. Record the approved package, supported architectures, required runtime, database or API prerequisites and the previous known-good state. Start with a bounded customer or order cohort, monitor exceptions and keep a tested way to pause new work without deleting the durable queue or losing reconciliation evidence.
Monitor reachability, authentication, latency, retry and dead-letter trends, external rate limits, installed version and reconciliation differences. Rotate credentials and exercise recovery before an emergency. Review vendor API or SDK changes and the adapter support matrix before upgrades. Retire obsolete credentials, mappings and data under the agreed security and POPIA operating process.
Decision-maker intent
Finance
A custom connector can do that only after finance chooses the document, approval, account, tax and due-date policy. SalesPro Hub does not currently claim a native automatic Xero invoice feature.
IT and security
Customer middleware or a future approved managed adapter owns the Xero consent and token lifecycle. Tokens must stay server-side, encrypted and out of logs.
Operations
The Inventory API can receive absolute quantities by SKU, but the business must define whether Xero-connected stock is sufficiently current and which system handles deductions.
Professional includes scoped APIs and signed webhooks for custom, customer-operated middleware. A managed Windows connector, remote configuration, heartbeat/version monitoring and managed recovery require Enterprise—and only become available for this named system after its real adapter passes the published release boundary.
Buyer decision guide
A good trial should prove the workflow with your data—not rely on a sales promise.
Implementation flow
Your middleware completes Xero OAuth and securely stores the selected Xero tenant relationship.
Persist the Xero contact ID as the SalesPro Hub external identity so renames and email changes never create a second customer.
Read only non-draft SalesPro Hub orders, validate the mapping, and create the chosen Xero document with an idempotency record.
Acknowledge the SalesPro Hub order with the Xero reference, then reconcile fulfilment and stock under one declared source-of-truth policy.
| SalesPro Hub field/event | Xero equivalent | Implementation note |
|---|---|---|
| customer.external_id | Xero ContactID | Stable contact identity. |
| order_number | Reference | Recommended connector deduplication key. |
| external_reference | Xero document number/ID | Returned after successful creation. |
| items[].sku | ItemCode | Validate before automated posting. |
| vat_rate / vat_amount | TaxType and calculated tax | Confirm inclusive/exclusive policy. |
Not currently. SalesPro Hub provides the REST and webhook foundation, while a custom connector must handle Xero OAuth and accounting entity mapping.
A custom connector can transform submitted SalesPro Hub orders into the chosen Xero document. Automatic posting is not built into SalesPro Hub itself and must follow your approval, tax and account-code policy.
Use the immutable Xero ContactID as the external customer identity. Do not merge on company name or email because both can change.
A Xero-connected inventory source can publish absolute quantities to SalesPro Hub by SKU. The implementation must prevent a delivery from being deducted twice.
Connected buying journey
Review the managed runtime, ERP, accounting, CRM and automation options before choosing a delivery model. Every page publishes its current support boundary, required custom work and Enterprise plan status.
Import real products and customers, capture a representative order, then scope the integration against evidence instead of assumptions.