If your General Ledger accounts are not reconciling to the sub-ledgers, the first question to ask is, 'When did the report last reconcile to the General Ledger?'. This will help in narrowing your search for the cause.
It is best practice to reconcile at least monthly. Reconciliation should be part of your normal reporting procedures. This way if an imbalance occurs it can be found quickly.
If your answer to the above question is that the General Ledger (GL) never reconciled, then searching for a cause may be a waste of time, depending on how material the imbalance is and whether it has significantly changed from the prior reporting period. It may be better to review the details of the sub-ledger report, BAS, GST Return as is appropriate for the situation, eg: for the Product Status report, perform a stocktake, whereas for the Supplier Ageing Report you might check back to unpaid invoices. Once the report / return is confirmed as best as you can, then pass a General Journal entry to force the GL to balance. Going forward you will now have a reference point to come back to and so will be able to correct settings, procedures, etc as you find causes for any future imbalances.
Check if any of the following scenarios below apply to your imbalance.
GL Postings have not been posted
If you post manually:
Run a GL Postings report for the sub-module, eg: Customers, Reports, Transactions, General Ledger Postings, do NOT use a date range. If transactions exist print the report for your records.
Go to General Ledger, Transactions, Other Modules, Post from Other Modules, and post missing entries to the required period.
If you have activated GL Automated Postings:
check if any transactions are being held in General Ledger, Transactions, Automated Postings, Transactions Pending.
Ensure any unposted entries are posted by addressing the issue that is blocking them from posting.
BAS / GST Return has not been updated
The BAS / GST Return must be separately updated in both Customers and Suppliers. This is separate to GL Postings.
NOTE: If you use a Cash Basis for your BAS / GST Return then it will NOT reconcile to your GST control accounts, this is normal.
Check through the transactions to be updated:
(Aust) Run the Customers, Period End, Customer BAS, BAS Allocations Report and untick Current Period and select Transactions to be Updated.
(NZ) Run the Customers, Period End, GST Return (NZ), GST Return Allocations Report and untick Current Period and select Transactions to be Updated.
Update transactions to the relevant BAS / GST Return period using any date range that is required:
(Aust) Open Customers, Period End, Customer BAS, BAS Update and select the BAS period you need, enter a date range if needed, and Accept (F9) to update.
(NZ) Open Customers, Period End, GST Return (NZ), GST Return Update and select the GST Return period you need, enter a date range if needed, and Accept (F9) to update.
Check report settings: ranges, calculation date, services included, etc.
Sometimes the settings used on a report is the cause of the imbalance.
For products, ensure zero and negative available stock is included.
For date-based products, ensure Transaction Date is selected.
GL Postings have doubled up as the GL Postings table was not cleared when running Post from Other Modules
Run the General Ledger, Reports, Transactions, Transactions by Account report for the control account, e.g.: Trade Creditors, and review the transactions for any entries that seem to repeat with the same amount and reference, but with a different batch number.
Check settings saved for each Attaché user to ensure the Delete Posted Transactions setting is ticked in Post from Other Modules.
Reverse the General Ledger batch to undo the duplicate.
General Journals incorrectly used to adjust the subledger/GST control account - Debtors/Creditors/Stock on Hand/GST/Cost of Assets
Look through the relevant Control Account transactions to identify transactions with a source that is not from a sub-ledger (Customers, Suppliers, etc.) as these could cause an imbalance. For example:
use the General Ledger, Reports, Transactions, Transactions by Account report, although this report does not list the source.
The source can be seen using General Ledger, Masterfiles, Enquire, enter the control account code, then F2 Actuals, and zoom in to the relevant period. Check the source by using F7 View.
Incorrectly dated transaction posted to incorrect period
Check the transaction date of postings from transaction reports, e.g. Sales Register, BAS / GST Audit Report.
If a transaction was incorrectly dated, the date entered could have caused the transaction to be posted into an incorrect period/report. If date ranges are used to post transactions, then this is likely.
For GL transactions these can be edited using Journals from Other Modules.
For BAS / GST Returns the transactions cannot be reallocated. The BAS / GST Return will need to be manually adjusted
Transactions posted to the incorrect period for date based
This can occur if the incorrect period is selected when using Post from Other Modules or BAS Update or GST Return Update.
For GL check transactions in other periods are dated correctly by using the Transactions by Account report, filtering for the control account and period.
For BAS and GST Returns check the BAS/GST Audit Report for other periods.
GL Set with incorrect control account has been added to the Masterfile of the Customer/Supplier/Product
The GL set applied to Masterfiles can be reviewed using the List Wizard, the following steps use Customers as an example, but this method can be used for all Masterfiles:
Go to Customers, Masterfiles, Customers, Enquire.
On Customer Code press F2 then F11.
Add the GL Set field to the table by selecting Add Columns.
Find the glset field in the Add Columns window.
Drag and drop the glset field onto the List Wizard window.
Or the GL Set applied can be viewed for any Masterfile by finding the GL Set or General Ledger Set field on the Masterfile.
To check the validity of a GL Set:
go to Setups, General Ledger, General Ledger Sets, Enquire.
On the Set Code field press F2 Find and select the GL Set Code used on the Masterfile.
Check the relevant GL Code applied for the Control account that is out of balance.
GL Control Account was manually changed in a Payment or Other Module Journal
The control account can be changed back in an Other Module Journal.
Use General Ledger, Transactions, Journals from Other Modules.
Select the Batch No the Transaction was posted by.
Accept F9 to proceed to the Entry screen.
Click on the Number field.
Press List F4 to see the transaction list.
Find the transaction with the incorrect sub-ledger control account code and press enter to return to the Entry screen, the selected transaction can now be edited.
Amend the Account Code field to the correct control account.
GL Set altered when entering a document causing incorrect control account to be used
Identify missing documents by reviewing related reports such as the Sales Register, Purchasing reports, etc.
Lookup the document and see if the G/L Set field is listed in the Header, check the zoom in of the Header as well
If it is not there, then more than likely the GL Set was not edited
If it is there, then a comparison of, for example, Sales for a period should be made with debits to the control account for Customers, or credits for Suppliers (alternatively ODBC could be used to check the GL Set applied).
Future dated transaction (date based)
A future date would leave the transaction as unposted or send it to the incorrect period.
A payment allocation was only partially posted
Check the Payments report and look for a payment or payments equaling the imbalance
If found, which would be very rare, enter a General Journal on the payment date for the imbalance
Dr Trade Creditors Cr Bank.
A batch from an Other Module is out of balance due to a server disconnection or similar
Run the All Transactions or Batch Report to find out of balance batches
Each batch that is out of balance would need to be corrected using General Ledger, Transactions, Other Modules, Journals from Other Modules.
Partial update or corrupt data
This is the last possibility and only applies after investigating all of the above and then only after being confirmed by a data investigation.