Troubleshooting Conversions

Brought Forward P&L Transactions (Sage)

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.

"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 desktop software.

Cause: Some transactions eg. bank transactions in desktop software can be entered without contact details being associated. When entering the corresponding transaction into online 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.

"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 Sage 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" 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" 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.

Overpayments with VAT (Xero only)

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).

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

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).

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).

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 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

Mid-month conversions and Report Dates (Sage)

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 (Sage)

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.