What we configure
Leads into a queue, opportunities with stages your manager can defend, cases with an owner, and portals that show a partner their own accounts and nothing else. Required fields land before a deal can be marked won.
Loading this page…
What We Build
Every engagement we sell is on this page: websites, mobile apps, Salesforce consulting, Salesforce integration, Xero, commerce, and the support that follows. Xero is a service here, not a separate destination and not a login to your books.
Website Development, Mobile App, Salesforce, Salesforce integration, and Xero sit with the commerce, connected-app, PWA, and support work from the same practice.
Service
This is the consulting and CRM work. We take an org from “we have licenses” to a system the team uses: the right cloud, the objects that match the job, security that matches who should see the record, and training on your own data. The cloud-by-cloud breakdown lives on Expertise. Connecting that org to Xero, a shop, or another system you are keeping is a different service.
Leads into a queue, opportunities with stages your manager can defend, cases with an owner, and portals that show a partner their own accounts and nothing else. Required fields land before a deal can be marked won.
A data load that was counted and sampled, people who have practiced on their own records, and a helpdesk for the first renewal cycle or campaign. Go-live is a date. The outcome you named in discovery is the measure.
Service
Salesforce integration connects the CRM to systems that stay in charge of their own work. Sales keeps the relationship. Finance, commerce, or the old database keeps what it is good at. Xero is the accounting connection: the table below is what moves, and what deliberately does not. The same engagement shape covers a Commerce Cloud or Shopify order, a payment capture, and a validated load off the system you are leaving.
Bank reconciliation stays in Xero. Forecasts and pipeline stages stay in Salesforce. The sync is the customer, the invoice, and the payment status.
| Salesforce | Xero | Direction | Why |
|---|---|---|---|
| Account | Contact (customer) | Both ways, one master per field | One customer. Legal name, billing address, and tax number have a written owner. |
| Contact | Contact person | Salesforce → Xero | The person who should receive the invoice, not a second unrelated contact. |
| Opportunity, Closed Won | Sales invoice, usually a draft | Salesforce → Xero | Finance checks tax and the account code before the invoice is approved and sent. |
| Product and price book entry | Item, coded to a revenue account | Salesforce → Xero | The line on the invoice matches what was sold. |
| Invoice status on the account | Invoice and payment | Xero → Salesforce | The rep sees paid, partial, or overdue without logging into the ledger. |
| A reduced or cancelled deal | Credit note | Whichever side the adjustment starts | A credit does not live only in someone’s inbox. |
Written for the Xero connection, and used the same way when the other system is a storefront or a file you are migrating.
01
We decide the source of truth for each field — legal name, billing address, tax number, email — and which opportunity stage is allowed to create an invoice. Invoices land as drafts for finance unless you explicitly want them approved on their own. We pick the match key (email, account number, or a stored Xero contact id) and name the person who fixes a duplicate or a rejected tax code.
02
The field mapping is a document, not a memory. On the Salesforce side we add the invoice number, status, amount due, and last payment date where sales will look for them. On the Xero side we reserve the account codes and contact treatment for CRM-originated invoices. A duplicate rule runs before the first sync. The pilot is one pipeline or a named set of accounts, not the whole org on the first afternoon.
03
Existing Salesforce accounts are matched to existing Xero contacts so we do not create a second customer for someone you already invoice. Open invoices are snapshotted so sales is not blind during cutover. We then run a handful of real closed-won deals from end to end: the invoice number appears, and a payment in Xero flips the status in Salesforce. The same standard we use for any Salesforce data load applies here — secure, validated, and checked before it is called done.
04
Sales learns which fields have to be filled before a deal can invoice: account, products, price, and a billing contact. Finance learns how to approve, code, and send, and where a rejected sync shows up. Both teams get a short runbook for mismatches. After go-live the helpdesk covers the connection the same way it covers Salesforce itself.
Service
For a business standing Xero up properly, leaving spreadsheets or another ledger, or cleaning an organisation that was switched on without a chart anyone agreed to. The same four beats we use everywhere else — discover, build, migrate, train — applied to the file your bookkeeper will close every month. The invoice that follows a closed-won opportunity is Salesforce integration, above.
We sit with the people who raise invoices, approve bills, and reconcile the bank. We write down the entities, currencies, and tax rates you already use, which bank accounts and payment services exist, and the reports that have to be right on day one — aged receivables, a management profit and loss, and any split by location or project. We agree a cutover date before anyone imports a file.
The Xero organisation is created or cleaned up: financial year, lock dates, invoice branding, default payment terms, and the payment services you will actually turn on. Users get a role that matches the work — adviser, standard, or invoice-only — instead of everyone as an adviser. Tracking categories are reserved for the two ways you need to slice a report, because Xero gives you two.
We map the current codes into Xero account types and retire the ones nobody posts to. Tax rates sit on the accounts that need them. Inventory items are added only where you sell stock or want item-level reporting. The bookkeeper signs the chart before any history is loaded, so go-live is not the moment the coding gets redesigned.
Customers and suppliers come across with email and tax numbers. Open sales invoices and bills are loaded at the cutover date, with opening balances for the bank, the control accounts, and equity. History is limited to the window we agreed — often the current financial year — rather than an unbounded dump. The opening trial balance is reconciled before anyone is told to start working in Xero.
Bank feeds are connected where the bank offers one, and statement import is set up where it does not. Repeating lines get reconciliation rules. Repeating invoices and bills are rebuilt for the contracts that should not be retyped. We leave a one-page close checklist: what is reconciled, what is locked, and who signs the month.
Owners, bookkeepers, and anyone in sales who raises an invoice practice on your file, not a sample company. The session covers raising and emailing an invoice, entering a bill with the source document attached, reconciling a bank line (and knowing when not to code it), reading aged receivables and payables, and adding a user or a tracking option without breaking the chart.
After go-live you keep a named person for month-end questions, a new tracking category, or a user change. It is the same posture as our Salesforce helpdesk: adoption and a place to call, not a project that ends the day the file is handed over.
Salesforce, the integration, Xero, a site, or the support after launch. If you are not sure which one comes first, say that on the form.