Xero FAQ

Xero will not allow the invoice to be imported into its database twice, even if the first version of the invoice has been deleted from Xero.

This is because Xero 'knows' that the invoice number has already been used in an import. It will not allow a second invoice to be imported with the same number.

You need to delete the original invoice in Case Manager too and create a new one. Export this new invoice to Xero.

This is almost certainly caused by Xero rounding the invoice data as it re-calculates invoice line item totals and GST on import.

The solution is to set the export option that effectively stops Xero re-calculating invoice values, see Xero export rounding.

There is no automatic updating in these situations.

If you change or add an adjustment to an invoice in Case Manager you will need to enter this change manually to the matching invoice in Xero.

Similarly, if you change an invoice in Xero you will need to create a matching adjustment in Case Manager to synchronise the two systems.

One possibility is that the payment that did not arrive was forward-dated.

When a payment arrives in Case Manager from Xero with a payment date in the future, Case Manager consults the value of your forward dating system setting:

If the Xero payment date is greater that the specified number of days into the future, the payment will not be added to Case Manager.

If you do need to enter such a payment in Xero you should temporarily disable this setting in Case Manager first.

See Further information about part payments.

The following applies when your server is not hosted by Chameleon Software.

In the unlikely event that your server environment goes down for 24 hours or more, there may be an issue with the Xero-Case Manager integration if payments are made in Xero during the outage. This issue also applies to a planned server outage, such as when the system is intentionally taken offline.

The issue occurs because when a payment is made in Xero, a webhook process is generated that tries to notify Case Manager about the payment. When the server is down Case Manager cannot receive this message, so the process fails.

As a result, the webhook enters "Retry" status. Xero 'realises' that it hasn’t received a successful response and retries with decreasing frequency for 24 hours.

After 24 hours of failed attempts, the webhook enters "Disabled" status and Xero disables it. The user is instructed to click the Re-enable webhooks button to re-activate their subscription.

This requires the user (or Chameleon Support via a screen share) to log into https://developer.xero.com/myapps, select the Webhooks tab, and manually re-enable the webhook to restore its functionality.

Note that any payments that are made during this disabled period will still be synchronised with Case Manager. Xero simply queues these events and sends them to Case Manager once the webhook has been re-enabled.

Information about webhook status can be found at:

https://developer.xero.com/documentation/webhooks/creating-webhooks

Xero has certain limits on how fast and how actively its integration can function. We've upgraded our side of the integration in order to get the best possible outcome for you.

Xero have the following limits when using their API

  • 60 calls per minute

  • 5000 calls per 24 hour window

Formerly payments coming from Xero were imported into Case Manager one by one.

Now we monitor all traffic going into and out of Xero.

Journaled invoices are still exported in batches of 50. However, when payments are flagged as ready for import from Xero, we group them into batches of 50 for acceptance into Case Manager. We continue to monitor this process in the background until all payments flagged by Xero are imported into Case Manager.

Thus, by grouping payments into batches the number of calls per minute and per day is reduced and hence, fits within Xero's limitations.