Every check Ledger Doctor runs
Check library 0.23.0 has 116 checks. This list comes from the library itself, so it's always the current one. New checks arrive on their own; see Update Ledger Doctor.
Shows as is the status a finding gives the check: see What Error, Attention and Warning mean. Close checks verify close checklist tasks rather than appearing under Issues to resolve. Records from checks marked "can be marked as expected" can be marked as expected by an approver, and checks with a one-click fix are covered in Preview, apply and undo a fix.
Server and backups (14)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
S01 | GP databases offline, missing or locked down A GP database is offline, missing, restricted to one user, or read-only, so GP can't work in it. | Error | |
S02 | No full backup in the last 7 days A GP database hasn't had a full backup in more than 7 days, or ever. If the server failed, that much work would be lost. Databases with no backup in 30 days show here too, and in their own red check. | Attention | |
S03 | No full backup in the last day A GP database hasn't had a full backup in more than a day, or ever. Most companies back up GP every night. Databases with no backup in 7 or 30 days show here too, and in their own checks. | Warning | |
S04 | Log backups missing A GP database is in full recovery but its transaction log hasn't been backed up in 24 hours. The log keeps growing until the disk fills. If your backups are taken by a tool that doesn't record them in SQL Server's backup history, mark the database as expected, naming the tool. | Warning | can be marked as expected |
S05 | No integrity check in 30 days SQL Server hasn't confirmed a GP database is free of corruption in the last 30 days. | Warning | |
S06 | Disk almost full (under 5% free) A drive holding GP databases or logs is under 5% free. When it fills, GP stops posting. | Error | |
S07 | Disk getting full (under 15% free) A drive holding GP databases or logs has 5% to 15% free space left. | Warning | |
S08 | SQL Server Agent stopped SQL Server Agent is set to run but is stopped, so scheduled backups, GP maintenance and the nightly scan won't run. If SQL Server Agent is meant to be off (another scheduler runs your jobs), mark it as expected. | Error | can be marked as expected |
S09 | SQL Agent jobs failed A SQL Server Agent job (often a backup or maintenance job) failed in the last 24 hours. Only a job whose latest run failed is listed, so it's clear once the job runs successfully. | Warning | |
S10 | Server checks can't see everything Ledger Doctor is missing a read-only permission, so some server checks (disk space or backups) can't see what they need and might look healthy when they aren't. | Warning | |
S12 | No full backup in over 30 days, or ever A GP database hasn't had a full backup in more than 30 days, or has never been backed up. If the server failed, all of that work would be lost. These databases also show under the 1-day and 7-day backup checks. | Error | |
S13 | Logins with full control of SQL Server These logins are in SQL Server's sysadmin role, so they can change any GP table directly, outside GP's security and audit trail. Keep the list to sa and the people who look after the server. A GP user's own login here ("a GP user signs in with it") means GP's security never applies to that person: GP users need DYNGRP only, so ask your SQL Server administrator to take the login out of sysadmin. Mark the ones you expect. | Attention | can be marked as expected |
S14 | GP sign-ins worth a look Who signs in to GP: users signed in for more than 24 hours (a session left open, or one GP lost track of; it holds a user license and can hold batches and records), and active GP users with access to a company who haven't signed in for 90 days (worth taking their access away). The page also shows the most people signed in at once each day for the last 90 days: compare the peak with your GP user licenses. Ledger Doctor keeps this history itself, checking every 5 minutes, so a session shorter than that may not show, and it can say who hasn't signed in only once it has 90 days of it. Sign the user out in GP (Microsoft Dynamics GP > Tools > Utilities > System > User Activity) or remove their access (User Setup or User Access Setup); mark the ones you expect. | Attention | can be marked as expected |
S15 | Database settings GP doesn't expect These GP databases have a SQL Server setting GP doesn't expect. Auto close on makes GP wait while the database starts again; auto shrink on slows GP down over time; a compatibility level under 130 means the database came from a SQL Server older than GP 18.5 supports and was never brought up to date; page verify other than CHECKSUM means SQL Server can't spot a damaged page; and a collation different from GP's system database makes GP fail or match names differently between databases. Ask your SQL Server administrator to change the setting (SQL Server Management Studio > the database's Properties > Options), after a backup. A collation can't simply be changed: ask your GP partner. Mark a setting that's that way on purpose. | Attention | can be marked as expected |
System (17)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C01 | Batches held by users who are logged out A batch is reserved for someone who isn't in GP anymore, so nobody else can open or post it. | Warning | one-click fix |
C02 | Leftover record locks Records are still locked by a GP session that ended, which causes 'record is being edited by another user' messages. | Warning | one-click fix |
C03 | Users stuck as logged in GP thinks these users are logged in, but their session is gone. This uses up licenses and blocks some routines. | Warning | one-click fix |
C04 | Stuck batches These batches are stuck in a busy status (posting, marked, receiving) and nobody is working on them. A batch that's only marked for posting, or shows Receiving and hasn't changed today, has started nothing: Ledger Doctor can make it available again (Fix). A batch stuck in a posting or interrupted status that still holds every transaction it counts (or is empty), none of them posted, can be made available the same way, so it can be posted again without posting anything twice (General Ledger, Payables, Receivables and Sales batches). For anything else, run Batch Recovery in GP (Microsoft Dynamics GP > Tools > Routines > Batch Recovery): it finishes or rolls back an interrupted posting correctly. Ledger Doctor never resets a batch that may have started posting, because it could post twice. | Warning | one-click fix |
C42 | Company access without a database user These GP users are given access to this company in User Access Setup, but have no user in its database, so they get a login error when they pick it. Clear and reselect their access in User Access Setup to recreate the user. | Warning | can be marked as expected |
C43 | Users missing from the DYNGRP role These GP users' database users aren't in the DYNGRP role, which is how GP grants table permissions, so they get permission errors. In GP, open User Access Setup (Microsoft Dynamics GP > Tools > Setup > System > User Access), clear the company for the user, save, then select it again and save. That adds them back to DYNGRP. | Warning | can be marked as expected |
C44 | Next note index is behind notes in use The company's next note index is at or below a note already in use, so new notes can overwrite or attach to the wrong record. Set the next note index past the highest one in use (Microsoft's note index script or GP Power Tools Note Fix), with everyone out of GP. | Error | |
C54 | Batches that claim transactions they don't have These batches show a transaction count and total in GP, but there's nothing in them. Ledger Doctor can remove an empty single-use batch (Fix): there are no transactions to lose. For a recurring batch, open it in its batch window and delete it if nobody needs it; if GP won't delete it, recount it first: Payables batches with Batches marked in Reconcile Payables Accounts, Receivables batches with Batch Information marked in Reconcile Receivables Amounts. | Warning | one-click fix |
C55 | Documents in batches that don't exist These unposted documents name a batch GP doesn't have, so they can't be found in a batch window. Run Check Links for the document's series (Microsoft Dynamics GP > Maintenance > Check Links), which puts them back in a batch. | Warning | |
C62 | Batch record with no batch ID GP has a batch record with no batch ID, which no batch window can open or delete. An approver can remove it with one click: no transaction can belong to a batch with no ID. | Warning | one-click fix |
C66 | SQL triggers on GP tables These SQL triggers run whenever GP saves a row in the table, outside GP's own logic. Add-ons and integrations use them, and old ones are a common cause of errors when saving or posting. Confirm each is still wanted, with whoever installed it; mark the ones you expect. | Attention | can be marked as expected |
C68 | GP or add-on versions that don't match These databases are on an older version of GP or of an add-on than the newest one installed, or their upgrade didn't finish. GP refuses to log in to a company that isn't upgraded, and an add-on can fail in some companies only. Run GP Utilities on the server to finish the upgrade, after a backup. Rows GP left behind for a deleted company are left out. | Warning | |
C69 | Users who own the company database These users are in the company database's db_owner role, so they can change any GP table directly, outside GP's security. GP users need only DYNGRP (User Access Setup gives it). Remove anyone who doesn't need it, after asking your SQL Server administrator. Mark the ones you expect. | Attention | can be marked as expected |
C70 | Database code added or changed in the last 30 days These stored procedures, views, functions or triggers in the company database were added or changed in the last 30 days. A GP update or a new add-on changes many at once, which is expected. One or two changed outside an update are worth asking about: custom code can change GP data. Mark the ones you expect. | Attention | can be marked as expected |
C86 | GP tables that differ from the other companies These GP tables don't have the same columns here as in the other GP companies on this server: a column this company is missing, one only this company has, or one with a different type or length. Companies on the same GP version should match, so this usually means an upgrade or an add-on's install didn't finish in this company, or someone changed a table by hand. GP fails on these with errors about a column or a conversion. Check that GP and every add-on are on the same version in every company (GP or add-on versions that don't match, C68), and run GP Utilities on the server to finish an upgrade, after a backup. A column an add-on adds in this company only can be marked as expected. | Warning | can be marked as expected |
C87 | GP auto procedures missing GP reads and saves each of its tables through a set of stored procedures it creates for that table. These tables are missing some of theirs here, though the other GP companies on this server have them, so GP fails on these tables with an error that names the missing procedure. Recreate them in GP: Microsoft Dynamics GP > Maintenance > SQL, choose this company's database and the product (Microsoft Dynamics GP for GP's own tables), select the tables listed, tick Create Auto-Procedure, and click Process. Do it when nobody is working in this company, after a backup. | Warning | |
S11 | GP users without a SQL login These GP users have no SQL Server login, so they can't sign in to GP. This usually happens after GP moves to a new SQL Server without its logins. Recreate the logins (Microsoft's capture_logins script, or reset the password in User Setup). A user who can't use any company is deleted in GP instead; its guide says how. | Warning | can be marked as expected |
General Ledger (22)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C05 | Hidden unposted journal entries Unposted journal entries exist with no batch, so you can't see them in GP. Ones with no lines are empty shells with no amounts. Ledger Doctor removes the empty shells. For entries with lines, run Check Links for the Financial series in GP (Microsoft Dynamics GP > Maintenance > Check Links), which puts them back in a batch you can find. | Warning | one-click fix |
C06 | Posted journal entries out of balance A posted journal entry has unequal debits and credits, so your trial balance doesn't balance. GP can't change a posted entry: post a correcting entry for the difference, then an approver marks this one as expected, naming the correcting entry. | Error | can be marked as expected |
C07 | Trial balance summary doesn't match detail The summary trial balance and the detail trial balance show different amounts for these accounts and periods (open or history years). For an open year's periods, an approver can rebuild the summary from the posted detail with one click; it can't touch a closed period. For the rest (beginning balances, history years, a summary row that's missing), run Reconcile in GP (Microsoft Dynamics GP > Tools > Utilities > Financial > Reconcile) for the year shown; it rebuilds the summary from the detail. | Error | |
C38 | Account category and posting type disagree This account's posting type (Balance Sheet or Profit and Loss) is the opposite of every other account in its category. Either the category or the posting type may be wrong. Year-end close uses the posting type, so it's worth a look. | Warning | can be marked as expected |
C39 | Control accounts allow journal entries These AP or AR control accounts have Allow Account Entry turned on, so people can post journal entries straight to them. The subledger never sees those entries, which is one of the most common reasons an aging stops tying to the GL. Turn it off in Account Maintenance. | Warning | can be marked as expected |
C40 | Inactive accounts that still have a balance These accounts are marked inactive but still have a balance this year. Nobody can post to them to clear it, and some reports leave inactive accounts out, so totals can look wrong. | Warning | can be marked as expected |
C45 | GL summary rows in the wrong year table Period summary rows for a history year are in the open-year table, or the other way round. GP never reads them there, but they confuse Reconcile and the summary tie-outs. An approver can remove them with one click (no report changes), then run Reconcile in GP (Microsoft Dynamics GP > Tools > Utilities > Financial > Reconcile) for that year. | Warning | one-click fix |
C46 | Large manual journal entries These journal entries were keyed in by hand for 25,000 or more and posted in the last 45 days. Large manual entries are the first thing an auditor looks at. Make sure each one has support, then mark it as expected. | Warning | can be marked as expected |
C47 | Round-amount journal entries These manual journal entries, posted in the last 45 days, total a round amount (10,000 or more, an exact multiple of 1,000). Round numbers usually mean an estimate or a plug. Make sure each one is supported. | Warning | can be marked as expected |
C48 | Journal entries posted to an earlier period These manual journal entries were posted in the last 45 days into a period that had ended more than 15 days before. They change numbers that may already have been reported. Confirm each one was meant for that period. | Warning | can be marked as expected |
C49 | Journal entries posted on a weekend These manual journal entries were posted on a Saturday or Sunday in the last 45 days. That's unusual for most finance teams and worth a second look. | Warning | can be marked as expected |
C50 | Journal entries entered and posted by the same person These manual journal entries of 10,000 or more, posted in the last 45 days, were entered and posted by the same GP user, so nobody else looked at them first. In a small team that can be normal: review them and mark them as expected. | Warning | can be marked as expected |
C51 | New accounts already in use These accounts were created in the last 45 days and already have entries posted to them. Confirm each was set up on purpose, with the right category and posting type. | Warning | can be marked as expected |
C52 | Reversing entries past their reversing date These reversing journal entries haven't been posted, and their reversing date has already passed. Posted now, the entry and its reversal land in periods that may already be reported. Post them, or fix the dates first. | Warning | can be marked as expected |
C53 | New year's beginning balances don't tie to last year After the GL year-end close, each balance sheet account should start the new year where it ended last year, with only the year's net income moving into retained earnings, and every profit and loss account should start at zero. These accounts don't. Something posted to the closed year without updating the new year, or the close was interrupted. When the closed year has no profit and loss history in GP to compare against (it was marked closed without its detail), it lists one row saying so instead. If the closed year's detail was never kept in GP (common after a migration or a history purge), there's nothing to compare against: mark that row as expected, with the reason. | Error | can be marked as expected |
C59 | Setup pointing to GL accounts that don't exist Posting setup, customers, vendors or items, or their classes, name a GL account that was deleted. Transactions that use it won't post where they should. Pick an existing account in the record's account window in GP. | Warning | |
C60 | Inactive accounts still used as defaults These inactive GL accounts are still the default in posting setup, on customers, vendors or items, or on their classes. GP refuses to post to an inactive account, so transactions that use the default stop at posting. Change the default, or make the account active again if it's still in use. | Warning | |
C63 | GL summary rows with negative totals These years have GL summary rows with a negative debit or credit total, which GP never writes itself. Run Reconcile for the year in GP (Microsoft Dynamics GP > Tools > Utilities > Financial > Reconcile) to rebuild the summary from the detail. | Warning | |
C64 | Unposted journal entries with no lines These unposted journal entries are in a batch but have no lines, so there's nothing to post. Open each in Transaction Entry (Transactions > Financial > General), or Clearing Entry (Transactions > Financial > Clearing) for a clearing entry, and delete it. | Warning | |
C67 | Accounts missing from GP's account index GP keeps each account and a separate index of account numbers, which lookups, SmartLists and integrations use. These don't agree, so an account can't be found by its number, or a number points at an account that's gone. Run Check Links for the Financial series, Account Master (Microsoft Dynamics GP > Maintenance > Check Links), after a backup. | Warning | |
C84 | Reversing entries whose reversal didn't come back right These reversing journal entries posted, but their reversal doesn't undo them: for some account the reversal is a different amount from the entry, or an account is missing from it, or the reversal is filed in a different fiscal period from its date. The accrual, or part of it, stays in the GL when it should have reversed. Look up the entry in GP (Inquiry > Financial > Journal Entry) and post a correcting entry for what's left, or ask your GP partner if the reversal's lines look damaged. A correcting entry fixes the books but can't change the posted lines this lists, so once it's posted an approver marks the row as expected, naming the entry. | Warning | can be marked as expected |
C88 | Beginning balances that don't roll forward from the year before Each fiscal year's beginning balance should be the year before's ending balance. Retained earnings also takes the year before's profit or loss, and profit and loss accounts start the year at zero. These accounts don't, by the difference shown. When the year before is closed, something changed it without updating this year, or the close was interrupted: your GP partner corrects it, often by reversing the year-end close and closing again. When the year before is still open, GP has no beginning balances for this year until it's closed, so these came from a copy or an import: have your GP partner remove them, then close each open year in order. When General Ledger Setup has no retained earnings account, one row says so: GP's year-end close can't carry profit and loss forward. A move to another system starts from these balances, so settle them first. With divisional retained earnings, retained earnings isn't compared. Once a difference is explained, an approver can mark it as expected. | Error | can be marked as expected |
Bank Reconciliation (2)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C41 | Old bank items still not cleared These checkbook transactions are dated more than 60 days before the checkbook's last reconciliation and still haven't cleared the bank: stale outstanding checks or deposits that never arrived. Void, reissue or explain them. Any stored with a negative amount are called out whatever their age: they move the balance the wrong way and need a look at how they were entered. | Warning | can be marked as expected |
C85 | Checkbook balances that don't match their transactions Each checkbook's current balance should be its last reconciled balance plus the transactions that haven't cleared the bank yet. These checkbooks are off by the difference shown: a transaction changed the balance without a record GP can reconcile, or a record is there that never changed the balance. It's usually an import, a void that stopped partway, or a change made outside GP, and GP carries the difference into every bank reconciliation. Find the transaction in GP's checkbook register (Inquiry > Financial > Checkbook Register) and correct it, or ask your GP partner to correct the checkbook's balance. Once it's explained, an approver can mark it as expected. | Warning | can be marked as expected |
Payables (10)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C08 | Paid payables documents still open These vendor documents are fully paid but haven't moved to history. Documents paid by a computer check or manual payment that's entered but not posted yet are left out: that's normal until the payment posts. Run Paid Transaction Removal in GP (Microsoft Dynamics GP > Tools > Utilities > Purchasing > Paid Transaction Removal) to move them to history. | Warning | |
C09 | Overapplied vendor documents A vendor document has been applied for more than its amount (or shows more remaining than it should). | Error | one-click fix |
C15 | Vendor balance doesn't match open documents The vendor's balance on the vendor card and summary inquiry is different from the total of its open documents. An approver can rebuild the balance from the open documents with one click, as GP's Reconcile does for the balance (Microsoft Dynamics GP > Tools > Utilities > Purchasing > Reconcile, which also rebuilds the period and year-to-date amounts). | Warning | |
C16 | Vendor document in both open and history The same voucher is in the open table and in history, so it can show twice and double-count in reports. | Error | |
C17 | Voided vendor document still open A voided payables document didn't move to history. While it shows an amount remaining, that amount is on the aging. An approver can set its amount remaining to zero with one click, as GP does when it voids. Then run Check Links for the Purchasing series in GP (Microsoft Dynamics GP > Maintenance > Check Links) to move it to history, and rebuild the vendor's balance. Once nothing remains, the Note column says which GP step moves it to history. | Error | one-click fix |
C18 | Hidden unposted vendor transactions Unposted payables transactions exist with no batch, so they can't be found or posted in GP. Run Check Links for the Purchasing series in GP (Microsoft Dynamics GP > Maintenance > Check Links), which puts them back in a batch you can find. | Warning | |
C19 | Open vendor documents with no vendor Open documents belong to a vendor ID that no longer exists, so they can't be opened, paid, or applied. | Error | |
C35 | AP aging doesn't tie to the GL The total of open vendor documents (what the aging shows today) is different from the GL balance of the AP control accounts. If nothing on the page explains what's left, an approver can have Ledger Doctor build an adjusting entry for it: an unposted journal entry in a GP batch, against an offset account they pick, to review and post in GP. A difference that unposted GL entries already account for isn't flagged: it's timing, and the unposted batches show under the close checks. | Error | |
C71 | Open Payables documents with no GL distributions These posted Payables documents are still open, but GP has no distribution lines for them, in either the open or the history table. GP can't show what they posted to the GL, and Check Links or a later edit can rebuild the lines wrong. Compare each one with its GL entry (the journal entry its posting created) before anyone edits it; your GP partner can re-create the lines from the GL entry. | Warning | can be marked as expected |
C81 | Payables documents showing payments that aren't applied These open vendor invoices show payments recorded on the document, but no payment is applied to them and their full amount is still open, or the payments recorded are more than the document. GP's vendor inquiry shows them as paid while the aging and the apply records say they aren't, so someone could pay them again, or a payment was lost from the apply records. Check the vendor's payments in GP before paying the remaining amount; your GP partner can correct the document from its payments. | Attention | can be marked as expected |
Receivables (14)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C10 | Sub-penny open balances Documents are left with a fraction of a cent remaining (like 0.00001) that can't be applied. | Warning | |
C11 | Overapplied customer documents A customer document has been applied past zero or shows more remaining than its original amount. | Error | one-click fix |
C20 | Customer balance doesn't match open documents The customer's balance on the customer card and summary inquiry is different from the total of its open documents. An approver can rebuild the balance from the open documents with one click, as GP's Reconcile does for the balance (Microsoft Dynamics GP > Tools > Utilities > Sales > Reconcile, which also rebuilds the period amounts); the aging buckets refresh at the next aging. | Warning | |
C21 | Customer document in both open and history The same receivables document is in the open table and in history. | Error | |
C22 | Voided customer document still open A voided receivables document didn't move to history. While it shows an amount remaining, that amount is on the aging. An approver can set its amount remaining to zero with one click, as GP does when it voids. Then run Paid Transaction Removal in GP (Microsoft Dynamics GP > Tools > Routines > Sales > Paid Transaction Removal) for the customer to move it to history, with both cut-off dates (transactions and checks) on or after the customer's latest document, payments included: GP skips anything dated later, and a payment left behind leaves its applications in both tables. Once nothing remains, the Note column says which GP step moves it to history. | Error | one-click fix |
C23 | Hidden unposted customer transactions Unposted receivables transactions exist with no batch, so they can't be found or posted in GP. Run Check Links for the Sales series in GP (Microsoft Dynamics GP > Maintenance > Check Links), which puts them back in a batch you can find. | Warning | |
C24 | Customer applications pointing to missing documents An application links a payment or credit to a document that no longer exists, so it can't be unapplied and the aging won't clear. | Error | |
C36 | AR aging doesn't tie to the GL The total of open customer documents (what the aging shows today) is different from the GL balance of the AR control accounts. If nothing on the page explains what's left, an approver can have Ledger Doctor build an adjusting entry for it: an unposted journal entry in a GP batch, against an offset account they pick, to review and post in GP. A difference that unposted GL entries already account for isn't flagged: it's timing, and the unposted batches show under the close checks. | Error | |
C56 | Payments and credits applied for more than their amount These payments, credit memos or returns are applied to more than their own amount, so the documents they pay show less owed than they should. Unapply the extra in GP's apply window and apply the right amounts. | Error | |
C57 | Customer checks entered twice The same customer check (same check number and amount) was entered as two receipts, and neither is voided. If the customer paid once, move what the extra receipt paid onto the other one, then void the extra receipt in GP. | Error | |
C58 | Applications in both the open and history tables GP kept these applications in both its open and history tables, so its apply windows and aging can count them twice. An approver can remove the extra copy with one click: the open copy when both documents are in history, the history copy when one is still open (GP works out an open document's amount remaining from the open copy). Only an exact duplicate goes, so no balance changes, even in a closed year. Ledger Doctor's tie-outs already count each once. | Warning | |
C61 | Customer or vendor balances with a fraction of a cent These customer or vendor summary balances carry a fraction of a cent that no document can clear. Run Reconcile for the series in GP to rebuild them from the documents. | Warning | |
C72 | Open Receivables documents with no GL distributions These posted Receivables documents are still open, but GP has no distribution lines for them, in either the open or the history table. GP can't show what they posted to the GL, and Check Links or a later edit can rebuild the lines wrong. Compare each one with its GL entry (the journal entry its posting created) before anyone edits it; your GP partner can re-create the lines from the GL entry. | Warning | can be marked as expected |
C75 | Amount remaining doesn't match the applications These open documents show an amount remaining that isn't what their applications leave: the amount less what's applied, with discounts and write-offs. In another currency, either of its two amounts remaining can be wrong. Aging, statements and the subledger total use the wrong figure. An approver can set it to what the applications leave; it changes posted amounts, so it needs a second approver and can't touch a closed period. Rows that say "No applications at all" show less remaining than the amount with nothing applied, and GP can't tell why. If an application was removed, an approver can set the full amount, under the same rules. If an earlier conversion loaded the balance this way, GP is right: mark it as expected. Fully paid with nothing applied counts as closed. A move to Sage Intacct takes what GP shows: a document still listed goes at GP's amount remaining, with a warning naming this check. | Warning | can be marked as expected |
Sales Order Processing (5)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C12 | Sales next-number collision The next sales document number is already used, so users get 'document number already exists' errors. | Warning | |
C25 | Sales lines with no document Unposted sales lines exist without their document, often after a crash. They can still hold inventory allocated. | Error | |
C26 | Sales document total doesn't match its lines The document's subtotal is different from the sum of its lines, so it will post the wrong amount. Run Reconcile-Remove Sales Documents in GP (Microsoft Dynamics GP > Tools > Utilities > Sales > Reconcile-Remove Sales Documents) for this document. A document in another currency is compared in that currency, because GP rounds each converted line to the cent. If a document is right as it is, mark it as expected. | Warning | can be marked as expected |
C27 | Sales document both unposted and posted The same sales document number is in both unposted and posted tables, which blocks posting and can double-count. | Error | |
C65 | Posted sales documents whose total doesn't match their lines These posted invoices or returns have a subtotal different from the sum of their lines. What posted to AR and the GL was the subtotal. Ask your GP partner which is right before correcting it with a credit memo or a new invoice. A document in another currency is compared in that currency. | Error | can be marked as expected |
Purchase Order Processing (4)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C28 | PO lines with no purchase order Purchase order lines exist without their PO. They can still inflate the On Order quantity. | Error | |
C29 | PO status doesn't match its lines The PO is closed but has open lines, or is open with every line closed, so it won't close or can't be received. Run Reconcile Purchasing Documents in GP (Microsoft Dynamics GP > Tools > Utilities > Purchasing > Reconcile Purchasing Documents). | Warning | |
C30 | Receipt total doesn't match its lines An unposted receipt or invoice subtotal is different from the sum of its lines (the 'negative total after re-entering lines' problem). Run Reconcile Purchasing Documents in GP (Microsoft Dynamics GP > Tools > Utilities > Purchasing > Reconcile Purchasing Documents). | Warning | |
C31 | Receipt both unposted and posted The same receipt number is in both unposted and posted tables. | Error |
Fixed Assets (4)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C32 | Asset transactions for deleted assets Depreciation or other asset transactions remain for an asset that was deleted, which breaks the FA GL posting. An approver can remove them with one click (no asset, book or GL amount changes). | Warning | one-click fix |
C33 | Assets with no book These assets aren't assigned to any book, so they never depreciate. Assign the asset to its books in GP (Cards > Fixed Assets > Book), or run Fixed Assets Reconcile (Microsoft Dynamics GP > Tools > Utilities > Fixed Assets > Reconcile). An asset still being set up has no book yet: add its book (Cards > Fixed Assets > Book) or, if it's right, mark it as expected. | Error | can be marked as expected |
C34 | Book records with no asset Book records remain for assets that were deleted, which can throw off FA reports and depreciation runs. Run Fixed Assets Reconcile in GP (Microsoft Dynamics GP > Tools > Utilities > Fixed Assets > Reconcile). An approver can remove them with one click (no asset or GL amount changes). | Warning | one-click fix |
C37 | Fixed assets don't tie to the GL Total asset cost or accumulated depreciation in Fixed Assets is different from the GL balance of the asset cost and accumulated depreciation accounts. | Error | can be marked as expected |
Inventory (3)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C13 | Inventory transactions missing their header Posting was interrupted and left inventory lines without a header, which breaks inquiries and reports. An approver can remove the orphan lines with one click (quantities on hand, cost layers and the GL don't change), then run Inventory Reconcile in GP for the item shown on each row. | Warning | one-click fix |
C14 | Inventory history rows with no site Historical inventory rows have a blank site, so the HITB report won't tie to the other inventory reports. If the history is right otherwise, an approver can mark the row as expected; GP's Historical Inventory Trial Balance reset (Microsoft Dynamics GP > Tools > Utilities > Inventory > Reset Historical Inventory Trial Balance) rebuilds it. | Error | can be marked as expected |
C73 | Inventory doesn't tie to the GL The value of what's on hand in Inventory (each receipt's remaining quantity at its cost) is different from the GL balance of the inventory account. Unposted GL entries on the account are shown separately: if posting them closes the gap, it's only timing. Otherwise look for journal entries made straight to the inventory account, or inventory transactions posted to a different account. If nothing on the page explains what's left, an approver can have Ledger Doctor build an adjusting entry for it: an unposted journal entry in a GP batch, against an offset account they pick, to review and post in GP. A difference that unposted GL entries already account for isn't flagged: it's timing, and the unposted batches show under the close checks. | Warning |
Payroll (3)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C74 | Payroll postings missing from the GL A payroll posting in the last 13 months didn't reach the GL in full: Payroll recorded more (or less) than the GL holds from that posting. Usually its GL batch is still waiting to be posted (Financial > Series Post); if not, the payroll expense and liabilities in the GL are wrong, and your GP partner can rebuild the entry from Payroll's posting history. If the difference is explained (posted to the GL another way, or a correction already made), an approver can mark the payroll posting as expected. | Warning | can be marked as expected |
C82 | Employees missing what their W-2 needs These employees were paid this year (in January and February, last year too), but their employee record is missing something a W-2 needs or has something it would be rejected for: a Social Security number that's blank, isn't 9 digits, can't be a real one (it starts with 000, 666 or 9, or has 00 or 0000 in it) or is the same as another employee's; a blank first or last name; or an address that's missing, has a blank street, city, state or ZIP code, or a US ZIP code that isn't 5 or 9 digits. Fix each one on the employee's record in GP (Cards > Payroll > Employee, and its Address button) before you print or file W-2s. Two employee IDs with the same number usually mean a rehire was set up again: they'd get two W-2s. Ledger Doctor never shows the Social Security numbers themselves. | Attention | can be marked as expected |
C83 | Last year's payroll year-end wage file isn't created Payroll checks were posted for last calendar year, but GP has no year-end wage file for that year, and W-2s are printed and filed from it. After the year's last payroll, run Payroll Year-End Closing (Microsoft Dynamics GP > Tools > Routines > Payroll > Year-End Closing) and create the wage file for the year, ideally before the first payroll of the new year. If your W-2s are done outside GP, mark it as expected. | Attention | can be marked as expected |
Multicurrency (5)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
C76 | Currencies in use that GP can't convert This company has documents or GL entries in these currencies, but GP can't convert them to your company's currency: the currency isn't set up, the company has no access to it or to an exchange rate table for it, or there's no exchange rate for the dates that need one (an open document's date, or the last period end, which revaluation uses). Enter the missing rates for the currency's exchange table (Microsoft Dynamics GP > Tools > Setup > System > Exchange Table Setup) or give the company access in Multicurrency Access Setup (Microsoft Dynamics GP > Tools > Setup > System > Multicurrency Access). | Warning | can be marked as expected |
C77 | Documents in another currency that don't match their exchange rate These Receivables and Payables documents are in another currency, but their multicurrency record is missing or incomplete, or their amount in your company's currency isn't their amount in the document's currency at the document's exchange rate. GP's aging, revaluation and realized gains and losses use those figures, so they'd be wrong. Your GP partner can correct the multicurrency record from the document's posting. | Error | can be marked as expected |
C78 | Balances in other currencies not revalued since the last period end These open documents and GL accounts hold balances in other currencies, and GP has no record of revaluing them since the last period end, so the unrealized gain or loss on them isn't in that period's GL. If your company revalues each month end, run Revaluation (Financial > Routines > Multicurrency > Revaluation) for that period. Mark it as expected if your company doesn't revalue. | Attention | can be marked as expected |
C79 | GL lines in another currency that don't match their exchange rate These posted GL lines are in another currency, but their amount in your company's currency isn't their originating amount at the line's own exchange rate, or the line has no rate. Reports in either currency disagree, and revaluation starts from the wrong figure. Your GP partner can correct them; a correcting entry in the GL fixes the functional side. A correcting entry fixes the books but can't change the posted lines this lists, so once it's posted an approver marks the row as expected, naming the entry. | Warning | can be marked as expected |
C80 | Realized gains and losses posted to another account These realized gain or loss amounts were posted to an account other than the one set up for their currency in Multicurrency Account Setup, so the gains and losses aren't all where your reports look for them. Check the currency's accounts (Financial > Setup > Currency Accounts) and move the amounts with a journal entry if they're wrong. A correcting entry fixes the books but can't change the posted lines this lists, so once it's posted an approver marks the row as expected, naming the entry. | Warning | can be marked as expected |
Close readiness (13)
| Check | What it looks for | Shows as | Also |
|---|---|---|---|
K01 | Unposted payables batches Payables batches are still waiting to be posted. | Close checklist | |
K02 | Unposted sales batches Sales batches are still waiting to be posted. | Close checklist | |
K03 | Unposted GL batches General ledger batches (not recurring) are still waiting to be posted. | Close checklist | |
K05 | Depreciation not run through last month-end Some active assets haven't been depreciated through the end of last month. An asset GP never depreciates forward (fully depreciated, land, a yearly book) can be marked as expected. | Close checklist | can be marked as expected |
K06 | Old periods still open These fiscal periods ended more than 45 days ago but are still open for at least one series, so people can still post into months that have already been reported. Each period is counted once; the columns show which series are open. Close them in Fiscal Periods Setup. | Close checklist | |
K07 | Bank reconciliations behind These active checkbooks have recent transactions but haven't been reconciled through a date in the last 45 days. Reconcile them in Reconcile Bank Statements. | Close checklist | |
K08 | Manual journal entries to control accounts These journal entries were posted straight to an AP or AR control account. The subledger never sees them, so the aging won't tie to the GL unless a matching subledger transaction was posted. Review each one. Ledger Doctor's own adjusting entries for a tie-out are left out. Once you've reviewed an entry, an approver can mark it as expected. | Close checklist | can be marked as expected |
K09 | Recurring batches behind These recurring batches still have a next posting date before this month, so last month's posting hasn't happened. Post them, or finish or delete batches you no longer use. If GP doesn't move a recurring batch's next posting date forward after it posts, mark it as expected once you've checked it posted. | Close checklist | can be marked as expected |
K10 | Next fiscal year isn't set up This fiscal year ends within 60 days (or already has), and the next year doesn't exist in Fiscal Periods Setup yet. Nobody can post into the new year, and the GL year-end close needs it. Set it up in Microsoft Dynamics GP > Tools > Setup > Company > Fiscal Periods. | Close checklist | |
K11 | Last year isn't closed in the GL A fiscal year that ended more than 120 days ago still hasn't been closed with the General Ledger year-end close. The new year has no beginning balances for balance sheet accounts until it is, and retained earnings doesn't roll forward. When more than one year is open, each row also names every open year with GL entries: only the current year, and last year for a few months, should be. A move to another system takes its opening balance from GP, and that balance has to be rolled forward through every year that isn't closed. Close the years one at a time, oldest first. | Close checklist | |
K12 | No usable retained earnings account General Ledger Setup has no retained earnings account, or it points to an account that's missing or inactive. The GL year-end close moves the year's profit or loss there and won't run without it. Check Microsoft Dynamics GP > Tools > Setup > Financial > General Ledger. | Close checklist | |
K13 | Unposted Inventory batches Inventory batches (adjustments, variances, transfers) are still waiting to be posted, so item quantities and the GL disagree. | Close checklist | |
K14 | Unposted Payroll batches Payroll batches still waiting to post, from GP's payroll batch list, with how many transactions each holds. Post each in GP (Transactions > Payroll > Batches), or delete an empty one there. | Close checklist | can be marked as expected |