"No Name" or "Default" customer or supplier balances

Symptom: Aged Debtors or Creditors balances include an amount against a No Name contact.

Cause (Sage): Often the result of journals being entered in Sage to the Debtors or Creditors Control Account.

Cause (QuickBooks): A possible corruption of data or other underlying problem that causes the control account to be different to the list of contact balances.

Check (Sage): Click File > Maintenance > Check Data. View the warnings and see if it reports “Sales/purchase aged balance disagrees with control account”. Expand the warning to see the amount they disagree by.

Check (QuickBooks): Generate a Trial Balance and compare the Debtors / Creditors Control balance to the Aged Receivables / Payables Report. Any diffence would result in the “No Name / Default” balance.

Explanation: It’s possible in Sage and QuickBooks for the list of customer or supplier balances not to agree to the control account. Other systems don’t allow these balances to disagree, so whilst converting the data we ensure the control account balances agrees from the old system to the new. We convert all the individual customer and supplier balances but the difference is posted to a “No Name” (Xero) or “Default” (QuickBooks Online)customer or supplier to ensure the total equals the control account.

Fix: Since this problem already existed in Sage or QuickBooks, it’s been transferred to your new software. Sage differences can be resolved (like it would in Sage) by determining which customer(s) or supplier(s) the journal in Sage related to, and posting the necessary transactions required to cancel the “No Name” or “Default” entries and re-post them to the relevant customer(s) and / or supplier(s). QuickBooks corruptions may require the data to be verified and rebuilt or possibly returned to Intui for fixing.

"No Name" (Xero) or "Default" (QuickBooks Online) contacts

Symptom: Online software shows transactions with the contact “No Name” or “Default Customer / Supplier”. This “No Name / Default” contact does not appear in the source software.

Cause: Some transactions eg. bank transactions in the source software can be entered without contact details being associated. When entering the corresponding transaction into the destination software a contact name may be required. Where this is the case we use “No Name” or “Default” as the contact name to highlight this in the converted data.

Check: Visit your customer and supplier contact lists in your online software and check if there’s a newly created “No Name / Default” contact.

Fix: Since entering a contact is a requirement you can’t remove this altogether. You could choose to edit the contact to rename it to something else.

VAT Accounts / Balances

Symptom: Sales and Purchase Tax Control Accounts are missing. VAT Balances don’t agree. Trial Balance totals aren’t the same in the old and new software.

Cause: Both Xero and Quickbooks Online operate a single VAT system account. All VAT postings are made in the one account.

Explanation: There’s no requirement to operate multiple VAT system accounts such as Sales and Purchase Tax Control Accounts as well as a VAT liability account.

Xero and Quickbooks Online combine all the transactions into one account to make things easier.

Check: Calculate the net balance of the Sales and Purchase Tax Control Accounts and the VAT liability account. This net figure should be the same as the one you see in Xero or Quickbooks Online.

Fix: None required (assuming the net balance of VAT system accounts equals the balance in online accounting software).

Invoices/Bills or bank transaction prior to the data I selected to convert from have been included

Cause: When entering the opening balances, the individual outstanding invoices/bills/overpayments etc. that sum to make the accounts receivable/payable control account balance need to be entered.

Explanation: Unpaid or partially outstanding invoices/bills/overpayments etc. need to be included so any subsequent payments or refunds made in the conversion period or later have a corresponding invoice, bill or transaction to match or allocate against.

VAT Returns

Symptom: Generating a VAT Return in the new software doesn’t produce the same figures as it does in the source software.

Cause: There could be a number of causes for this but a common cause is that the source software included changes that were made to transactions that had already been submitted in a previous VAT Return. Please also refer to the VAT section of the Limitations pages (Xero / QuickBooks Online / Sage Business Cloud Accounting).

Explanation: During the conversion process there’s no way to indicate to Quickbooks Online or Xero that changes have been made to transactions previously submitted in VAT returns. Since the transaction will be dated in a previous VAT period, Quickbooks Online and Xero expect it have been included in the VAT Return for that period.

Fix: For a VAT Return yet to be submitted, we suggest referring to the source software to determine the correct values or generating a partial VAT Return. You may need to adjust the VAT Return figures in QuickBooks Online or Sage Business Cloud Accounting or send amended figures direct to HMRC instead of filing through Xero (the incorrect VAT Return would still need to be published in Xero). Going forward Quickbooks online and Xero should automatically bring amendments or new postings to previous VAT periods into the current VAT return.

Further reading: VAT Returns Don’t Agree

Movemybooks Suspense Account

Symptom: A new account is present in the chart of accounts called “Movemybooks Suspense Account”.

Cause: Some transaction types cannot be converted from one system to another. We create and use the Movemybooks Suspense account to facilitate the entry of a representation of the transactions in the destination.

Explanation: Certain transaction types or entries cannot be entered in the same way in the destination as they are in the source. The transaction type may not be present in the destination or the journals may not be possible via that particular transaction type. Sometimes two transactions needs to be posted in the destination to represent a single transaction from the source system. We often need to post one side of double-entry to the Movemybooks Suspense Account. These will always net off so that there should never be a balance in the Movemybooks Suspense Account.  

Fix: No fix is required.


Brought Forward P&L Transactions

Symptom: Unusual journals on the last day of the financial year that reverse on the first day of the following financial year

Cause: Brought Forward P&L Balances

Explanation: Sage requires a year-end routine to be completed. As part of this process, ledger year end transactions are posted to “clear down” P&L accounts and reset them for the following year. Where transactions are posted after the year end has been completed, and the transaction is dated in the prior year, Sage will include this as a brought forward balance. These transactions are therefore included in Sage in the current year despite the transaction being dated in the previous year.

Online software doesn’t usually have a concept of a year-end routine or ledger year end transactions. Any transaction posted will therefore be included in the period of the transaction date.

Check: Generate a “Brought Forward” Trial Balance in Sage. If you see any P&L balances then these are likely to be transactions posted after the year-end routine has been run. They should be the balances seen in the journals and the reversing journals.


Fix: None required. The transactions have been converted into the new system with the same details as those included in Sage. The difference is caused by the way each software handles the transactions.

Mid-month conversions and Report Dates

Symptom: Balances appear different. It’s not possible to generate mid-month report date in Sage. Only options for the Trial Balance is to include future transactions.

Cause: Sage won’t always let you choose a specific date to run a Trial Balance report to compare with converted data. Alternatively the year-end may not have been completed in Sage.

Explanation: If a year end hasn’t been completed in Sage then after 12 months the only option when running a Trial Balance may be to select “Future” for the report date. This will mean Sage is generating balances for a period starting at the beginning of the last financial year right up past the previous year end right up to the last transaction entered. The “Future” Trial Balance figures will be for a period of more than 12 months and may include future dated transactions.

Example: A 31st March 2016 year end hasn’t been closed in Sage. If a “Convert to” date of 30th September 2016 was selected but the backup file included data for October 2016 then the Sage Trial Balance will include transactions from 1st April 2015 right up to the latest October 2016 transaction in the “Future” report. Comparing this “Future” trial balance covering 19 months with that in your new software that automatically starts from the the current year (eg. per the above example 1st April 2016 to 30th September 2016 being 6 months) will provide different results because of the different dates being used.

Even if a year end hasn’t been completed, if you choose a mid-month “Convert to” date then you won’t be able to choose a mid month Trial Balance date in Sage to use for comparison.

Fix: If the conversion was at a month end but the Sage Trial Balance only displays a “Future” option, then take a backup before running the year-end. This will then allow you to select a month end in the following year when generating a Trial Balance.

If the conversion was to a mid-month date, there arne’t any “fixes”. Assuming there aren’t any future dated transactions, the easiest solution is not to work in the desktop software after initiating the conversion. Doing so may mean having to duplicate data entry in the online system post-conversion anyway.

There isn’t any reliable solution to being able to generate reports on custom dates but it is possible in Sage to generate the balance on one nominal account by reviewing the Nominal Activity for a specified custom date range. This should at least indicate if there are transactions in Sage after the “convert to” date of your conversion.

Chart of Accounts

Symptom: Balances disagree. Balance sheet accounts show on P&L or vice versa.

Cause: A partial chart of accounts in Sage or overlapping High and Low values

Explanation: A partial chart means that at least some of the nominal codes are not represented in the chart. Similarly if an account code is used that could sit in multiple accounts our conversion won’t know which it should use. This can lead to P&L accounts in Sage being interpreted as Balance Sheet Accounts once converted or vice versa. The cumulative properties of Balance Sheet accounts mean the converted balances don’t agree to the P&L balances that are “zero’d down” each year.

Fix: Ideally the Sage chart should be amended to be complete and free from overlapping code ranges before the conversion takes place. Where this problem has already occurred, if there’s only a few affected accounts you could attempt to calculate what the converted balance would be if the account type were switched from P&L to Balance Sheet or vice versa.

If most of the chart has been affected this could take too much time. You could instead choose to accept the data as it is and then to amend the chart later before reviewing the figures. Alternatively you could consider contactacting either Intuit or Xero and request they offer to pay again for a second conversion. If accepted the chart can be rectified prior to providing us with the latest backup for converting.


Overpayments with VAT

Note: This usually just relates to users operating the Cash VAT Scheme with customer or supplier payments on account.

Symptom: Account balances are correct but VAT returns are incorrect.

Cause: Limitation in Xero to post overpayments with VAT.

Explanation: Xero allows either Prepayments or Overpayments to be entered. Prepayments cannot be posted to an Accounts Payable or Receivable Control Account but can be posted with any VAT rate.

Overpayments can only be posted to the Accounts Payable or Receivable Control Accounts and with No VAT (outside the scope of VAT).

Overpayment and Prepayment

It’s not therefore possible to enter a transaction posted to the Debtors or Creditors Control account with VAT.

Movemybooks approach: Since the system limitations in Xero prevent us from converting accounting and VAT data correctly, we’ve opted to ensure the accounting data is correct.

Fix: To prevent duplicating figures on VAT Returns of different periods, a manual adjustment on the next few post conversion VAT Return submissions is likely to be necessary. You might like to consider contacting Xero about this issue.

Associated links:

AccountingWeb discussion

Xero Business Community

Overdue invoices/bills

Symptom: The Xero Dashboard figure for invoices/bills overdue may be more than the awaiting payment amount or seem unreasonable.

Cause: Xero does not take credit notes or overpayments into account when calculating the overdue amount.

Explanation: The screen below displays how Xero calculates the overdue balance ignoring credit notes.

This is the Dashboard view of invoices owed:

Overdue invoice

Drilling into the overdue amount of £120 reveals the overdue invoice:

By clicking on All invoices tab this also reveals the credit note not included in the overdue balance:

Overdue invoice credit note

Missing Customers / Suppliers

Symptom: Looking at Customers or Suppliers in Xero shows less than expected.

Cause: Contacts without an invoice or bill raised against them will display as “Contacts” but not “Customers” or “Suppliers”

Explanation: If a contact is present in the source system but has no outstanding transactions at the conversion start date and no transactions in the conversion period then Xero categorises this as a “Contact” until an invoice or bill is raised against the contact.  

Fix: No fix is required.


Trial Balances don't agree

Cause: KashFlow provide the option to “Include Opening Balance” when generating a Trial Balance report.

Explanation: Most accounting systems generate Trial Balances with all Balance Sheet accounts including opening balances and all P&L accounts excluding opening balances. KashFlow’s Trial Balance doesn’t provide any option to run the trial balance this way.

Fix: When generating the Trial Balance in KashFlow, you can compare the Balance Sheet accounts with opening balances to the destination Balance Sheet accounts. When comparing the P&L accounts in KashFlow the Trial Balance needs to be re-run without opening balances included.