Home 1099 forms accounting software microsoft dynamics gp tax reporting

Dynamics GP Vendor 1099 Printing Issues: Troubleshooting and Solutions

Updated: • 0 • min read
Table of Contents

This article addresses common issues encountered when 1099 forms fail to print for vendors within the Payables Management module in Microsoft Dynamics GP. Properly generating 1099s is a critical year-end task for businesses, ensuring compliance with tax regulations for payments made to certain vendors. Understanding the various configuration points and transaction details is key to resolving printing problems. This guide provides detailed steps and explanations to help identify and rectify the reasons why a vendor’s 1099 might not be generated as expected.

Symptoms

The primary symptom is that when attempting to print 1099 forms for a specific year, one or more vendors that are expected to receive a 1099 do not appear on the printed report. This can cause delays in year-end tax filing and require immediate investigation to determine the root cause. Users may verify the vendor’s 1099 setup and transaction history but still find the vendor or the correct amounts missing from the generated forms.

Cause

Several factors can contribute to a vendor’s 1099 not printing correctly in Dynamics GP. These reasons typically involve misconfigurations in the vendor setup, incorrect transaction handling, issues with payment application dates, or discrepancies in accumulated 1099able amounts. Identifying the specific cause requires a systematic review of the vendor’s profile, transaction history, and system-wide 1099 settings.

Resolution

Troubleshooting why a 1099 doesn’t print involves checking several key areas within Microsoft Dynamics GP. Each potential cause has specific steps to verify configuration or data. It is recommended to check these points methodically to isolate the problem. Remember that changes to setup often only affect future transactions, requiring specific utilities or manual adjustments for historical data.

Vendor is Not Set Up as a 1099 Vendor

One of the most fundamental reasons a 1099 will not print is if the vendor record itself is not flagged as a 1099 vendor with the appropriate tax information. This is the initial setting that tells Dynamics GP to track 1099able payments for this specific vendor. If this step was missed during vendor creation or later setup, no 1099 will ever be generated for them.

To verify and correct this:
1. Navigate to the Cards menu.
2. Point to Purchasing.
3. Select Vendor.
4. Enter or look up the Vendor ID in question.
5. Click the Options button in the Vendor Maintenance window.
6. In the Vendor Maintenance Options window, check the Tax Type and 1099 Box fields. Ensure that a Tax Type (e.g., Miscellaneous, Nonemployee Compensation) and a valid 1099 Box Number (e.g., Box 7 for Nonemployee Compensation, Box 1 for Rents) are selected.
7. If these fields were previously blank or incorrect and you update them now, understand that this change is not retroactive. Payments made before the vendor was correctly configured will not automatically update the 1099 history. Additional steps, such as using update utilities, will be required to correct historical 1099 amounts for this vendor. Save any changes made in the Vendor Maintenance Options and Vendor Maintenance windows.

Incorrect 1099 Type Selected During Printing

Dynamics GP allows printing 1099s by different types (e.g., Miscellaneous, Interest). The type selected in the Print 1099 window must match the Tax Type configured for the vendor. If a vendor is set up as ‘Miscellaneous’ but the user attempts to print only ‘Interest’ 1099s, that vendor will not appear on the output.

To verify the print settings:
1. Go to the Microsoft Dynamics GP menu.
2. Point to Tools, then Routines, then Purchasing.
3. Select Print 1099.
4. In the Print 1099 window, carefully review the 1099 Year and 1099 Type selections. Confirm that the Year is correct for the reporting period (e.g., 2024 for payments made in 2024) and that the 1099 Type selected matches the Tax Type configured in the vendor’s Options window.
5. Ensure that any range restrictions (Vendor ID, Name, etc.) are not inadvertently excluding the vendor you are troubleshooting. Try printing for just the specific vendor or a small range that includes them to isolate the issue.

Vendor Did Not Exceed Minimum Reporting Threshold

The Internal Revenue Service (IRS) sets minimum payment thresholds for issuing 1099 forms. Dynamics GP respects these thresholds based on the configuration in the Payables Management Setup. If the total 1099able amount paid to a vendor during the calendar year falls below the minimum amount specified for their particular 1099 Type and Box, Dynamics GP will not print a 1099 form for that vendor.

To check the minimum amounts:
1. Go to the Microsoft Dynamics GP menu.
2. Point to Tools, then Setup, then Purchasing.
3. Select Payables.
4. In the Payables Management Setup window, click the 1099 Setup button.
5. Review the minimum amounts listed for each 1099 Type and Box Number. For example, for Tax Type ‘Miscellaneous’ and Box 7 ‘Nonemployee Compensation’, the standard IRS threshold is \$600.00. This means a vendor must have accumulated at least \$600.00 in paid 1099able amounts within the specified year to trigger a 1099 form.
6. Compare the vendor’s actual 1099able payment total for the year (which can be viewed in the Vendor 1099 Details window, discussed later) against the threshold defined in the 1099 Setup window. If the vendor’s total is below the threshold, the system is functioning correctly by not printing the form according to the setup.

Invoices Are Still Open and Not Paid

Dynamics GP tracks 1099able amounts based on the payment date or apply date, not the invoice date. Only amounts from invoices that have been fully or partially paid and applied will contribute to the vendor’s 1099 total for the year in which the payment occurred. If invoices for a vendor are still sitting in an open state (unpaid or unapplied), the amounts from those invoices will not be included in the current year’s 1099 reporting.

To investigate the status of invoices:
1. Use Inquiry windows to review the vendor’s transaction history.
2. Navigate to Inquiry, point to Purchasing, and select Transaction By Vendor.
3. Enter the Vendor ID and ensure that filters include Open and Historical transactions for the relevant year.
4. Examine the list of transactions. Look for invoices that are dated within the reporting year but show an open status or have not been fully applied by payments within that year.
5. Any 1099able amounts associated with these open invoices will not be reported until they are paid or applied to payments in the appropriate calendar year.

Vendor Was Set Up as 1099able After Invoices Were Paid

Similar to the scenario where the vendor was never set up correctly, if a vendor was designated as 1099able after some or all of their invoices for the year were paid, those payments made before the setup change will not automatically be included in the 1099 totals. Dynamics GP primarily flags transactions for 1099 reporting at the time they are entered or paid, based on the vendor’s setup at that moment.

This situation specifically requires a retroactive update method to adjust the 1099 history for the payments made when the vendor was not marked as 1099able. The methods for updating historical 1099 data are discussed in detail in the Frequently Asked Questions section below. Simply changing the vendor’s setup now will only impact future payments.

1099 Amount Field Was Cleared on the Invoice

When an invoice is entered for a vendor correctly configured as 1099able, Dynamics GP automatically populates the 1099 Amount field on the transaction entry window with the total invoice amount (or the amount subject to 1099 reporting based on account setup, if configured). However, users have the ability to manually edit this field before the invoice is posted. If this amount was inadvertently or intentionally changed to \$0.00 during invoice entry or editing, then that specific invoice’s value will not contribute to the 1099 total, even after it is paid.

To check historical 1099 amounts on individual invoices:
1. Navigate to Inquiry, point to Purchasing, and select Transaction By Vendor.
2. Enter the Vendor ID and include History in the display options.
3. Locate the specific invoice in question from the list.
4. Click on the Document Number link to drill down into the transaction details.
5. In the Transaction Inquiry Zoom window, look for the 1099 Amount field. Verify that it contains the expected value and is not \$0.00.
6. Note that if the invoice originated from the Purchase Order Processing (POP) module, the 1099 Amount field might be reviewed in the Receivings Transaction Inquiry Zoom window after drilling down from the POP invoice. Just like in Payables, this field could have been zeroed out by a user during the receiving or invoicing process in POP.

Frequently Asked Questions

Working with 1099s often brings up specific questions about how Dynamics GP handles the data. Here are some common inquiries and their detailed answers.

Q1: How are 1099 values updated?

A1: The 1099 values in Dynamics GP are primarily updated based on the date payments are applied to invoices, credit memos, or returns that have a 1099able amount. The system looks at the apply date of the payment transaction (like a check) to determine which reporting year the 1099able amount falls into.

Consider these scenarios to illustrate the payment date rule:

  • Scenario 1: An invoice is dated November 27, 2024. A check paying this invoice is dated December 11, 2024. When this payment is applied, the 1099able amount from the invoice will be included in the vendor’s 1099 total for the 2024 calendar year because the application occurred in 2024.
  • Scenario 2: An invoice is dated November 27, 2023. A check paying this invoice is dated January 11, 2024. When this payment is applied, the 1099able amount will be included in the vendor’s 1099 total for the 2024 calendar year, even though the invoice was from 2023. The reporting year is determined by the payment/apply date.
  • Scenario 3: An invoice is dated May 1, 2024, and has not been paid or applied to any payment yet. This invoice’s 1099able amount will not appear on any 1099 form until it is paid and the payment is applied to it. The amount will be reported in the 1099 year corresponding to the payment’s apply date.

It’s important to distinguish this from reports like the Historical Aged Trial Balance (HATB), which typically removes documents based on the check date or the period the check was posted, not necessarily the apply date within Payables history, although for 1099 purposes, the application date is the driving factor for reporting year.

Q2: How do you update 1099 amounts for vendors that weren’t set up as 1099 vendors or were switched halfway through the year?

A2: Correcting 1099 information retroactively for vendors whose setup was incorrect or changed requires specific tools or manual intervention because changing the vendor card setup only affects future transactions. Dynamics GP provides several methods to achieve this:

  • Method 1: Manually Update 1099 Details Window

    • Navigate to Cards, point to Purchasing, and select 1099 Details.
    • Select the Vendor ID and the relevant Year.
    • This window displays the accumulated 1099 amounts by Box Number for the selected year.
    • You can manually edit the amounts in the fields shown here to reflect the correct 1099able payments for the year.
    • Caution: While simple, manual edits in this window are fragile. Running certain reconcile processes (specifically the Calendar Year Reconcile) or using other update utilities can potentially overwrite these manual changes, recalculating the amounts based on transaction history, which may still be incorrect if the underlying transactions weren’t flagged as 1099able. Use this method with care and understand its limitations.

  • Method 2: Use the 1099 Modifier (Professional Services Tools Library - PSTL)

    • If PSTL is installed and configured (it’s a separate component usually provided with Dynamics GP), it includes a 1099 Modifier tool.
    • This tool is powerful as it can iterate through historical transactions for a vendor within a specified year and recalculate the 1099 amounts based on the vendor’s current 1099 setup or specific criteria you provide.
    • This is particularly useful for vendors who were marked as 1099able late in the year; the tool can go back and include previously paid transactions that should have been 1099able.
    • Warning: PSTL tools perform direct data manipulation. Always perform a full database backup before using any PSTL utility, especially the 1099 Modifier. Using this tool incorrectly can lead to data inconsistencies.

  • Method 3: Update 1099 Information Utility

    • Navigate to Tools, point to Utilities, point to Purchasing, and select Update 1099 Information.
    • This utility allows you to change the 1099 status and associated amounts for a range of vendors and years.
    • Starting with Microsoft Dynamics GP 2013 and later, this utility was significantly enhanced. You can select the Vendor and 1099 Transaction radio button. This option allows you to change a vendor’s 1099 status retroactively for a specific year range.
    • The “FROM” and “TO” pick lists include an option for Not a 1099 Vendor. This is crucial. You can select a range of vendors and use the “FROM: Not a 1099 Vendor” and “TO: [Desired Tax Type/Box]” options to effectively mark past transactions as 1099able for vendors who were previously not configured correctly for that year.
    • Conversely, you can use “FROM: [Incorrect Tax Type/Box]” and “TO: Not a 1099 Vendor” to remove 1099 reporting for vendors who were incorrectly marked.
    • This utility recalculates the 1099 amounts based on the transactions that meet the criteria within the specified year range and updates the 1099 history tables (PM00202 and PM00204).

  • Method 4: Edit 1099 Transaction Information Window

    • Navigate to Transactions, point to Purchasing, and select Edit 1099 Transaction Information.
    • This window provides a granular level of control, allowing you to view and edit the 1099able amount, Tax Type, and Box Number on a per-transaction basis for a specific vendor and year.
    • Only transactions for vendors already marked as 1099able will appear here initially. However, if you’ve used Method 3 or PSTL to mark transactions, they should appear here.
    • You can modify the 1099 Amount, Tax Type, and Box Number for individual posted debit documents (invoices). For credit documents (credit memos, returns), you can typically only edit the Tax Type and 1099 Amount, as they reduce the reportable total.
    • After making changes, click the Process button. This saves the edits and can print the PM Update 1099 Trx Information Audit report, detailing the modifications. This method is excellent for correcting isolated transaction errors or adjustments that shouldn’t apply globally to a vendor.

Here is a comparison of the methods:

Method Granularity Data Scope Ease of Use Risk Best For
Manual 1099 Details Vendor/Year Summary totals Easy Moderate Small, quick fixes; prone to being overwritten
PSTL 1099 Modifier Vendor/Year/Trans Recalculates All Medium High Mass retroactive updates (with caution)
Update 1099 Information Utility Vendor/Year/Trans Bulk Status Change Medium Moderate Changing vendor 1099 status retroactively
Edit 1099 Transaction Info Transaction Specific Docs Medium Low Correcting individual transaction errors

Q3: What documents will update 1099 amounts?

A3: 1099 amounts are updated when transactions marked as 1099able are involved in a payment application process. The core principle is that a reportable payment has occurred.

Here’s how different document applications affect 1099 amounts:

  1. Invoice applied to a Computer Check or Manual Check: If an invoice has a 1099 Amount greater than zero, applying a payment document (check) to it will add that 1099 Amount to the vendor’s 1099 total for the year of the check’s apply date.
  2. Invoice applied to a Credit Memo (with zero 1099 Amount): If an invoice with a 1099 Amount is applied to a credit memo that has a zero 1099 Amount, the net effect on the vendor’s open balance is a reduction, but the positive 1099 Amount from the invoice is still captured for reporting because the credit memo didn’t negate the reportable payment nature (or rather, it’s treated differently than a credit memo with its own 1099 amount).
  3. Invoice applied to a Return (with zero 1099 Amount): Similar to credit memos, applying an invoice with a 1099 Amount to a return with a zero 1099 Amount will record the invoice’s 1099 amount for reporting.
  4. Voiding a Check applied to an Invoice: If a check that was applied to an invoice (and thus recorded a 1099 amount) is subsequently voided, Dynamics GP will reverse the 1099 amount associated with that application in the history tables. This correctly reduces the vendor’s 1099 total for the year the check was originally applied, as the payment effectively didn’t happen.

Q4: What documents won’t update the 1099 amount?

A4: Certain scenarios or document types do not trigger an update to the 1099able amounts. These generally involve transactions that don’t represent a reportable payment or where the 1099able amounts net out.

Here are scenarios where the 1099 amount typically won’t be updated:

  1. Invoice applied to a Credit Memo (where both have a 1099 Amount): If an invoice with a positive 1099 Amount is applied to a credit memo that also has a negative 1099 Amount (representing a reduction of a previously reported 1099able expense), the two amounts will net each other out. If the net effect is zero or negative, no positive 1099 amount is added for reporting from this specific application.
  2. Invoice applied to a Return (where both have a 1099 Amount): Similar to the credit memo scenario, if an invoice with a 1099 Amount is applied to a return with a corresponding negative 1099 Amount, the amounts will net out, and no amount will be added to the 1099 total from this application.
  3. Voiding an Open Invoice: Voiding an invoice that is still in an open state (not paid or applied) will not affect 1099 amounts. This is because no payment has been made against this invoice yet, and thus no 1099able amount has been recorded for reporting purposes.
  4. An Invoice Saved or Posted But Not Applied: An invoice with a 1099 amount will not contribute to the vendor’s 1099 total until it is applied to a payment document (like a check) or a document that reduces it (like a credit memo or return). The act of merely posting the invoice does not update the 1099 history.
  5. Invoice Where 1099 Amount Was Manually Cleared: If, during the entry or editing of an invoice, a user manually changed the 1099 Amount field to \$0.00 before posting, that invoice will not update the 1099 history upon payment. The system only tracks the value present in the 1099 Amount field at the time of payment application.
  6. Credit Memo Keyed With a 1099 Amount (and not yet applied): A credit memo with a 1099 Amount, similar to an invoice, does not impact the 1099 history until it is applied to another document (usually an invoice). The application date will determine when the negative 1099 amount is factored into the vendor’s total.

Q5: If I run a reconcile, what 1099 data will be changed?

A5: The Reconcile utility in Payables Management recalculates summary information based on the detail transaction records. Running specific reconcile processes can impact 1099 data, potentially correcting inconsistencies but also potentially overwriting manual adjustments.

Here’s how different reconciles affect 1099 data:

  • Reconcile - Summary: Running a summary reconcile will recalculate the summary totals for vendors and documents based on the transaction detail tables (PM10000, PM20000, PM30300). Specifically, it will correct fields like TEN99ALIF in the vendor summary table (PM00204) and the TEN99AMNT in the vendor master table (PM00200) based on the accumulated amounts found in the 1099 detail history table (PM00202) and the transaction history (PM30300). Manual edits made directly to the 1099 Details window (PM00202 or PM00204 fields) might be overwritten if they don’t align with the calculated totals from the underlying transactions.
  • Reconcile - Calendar Year: This reconcile option is specifically designed for 1099 reporting. It reviews the applied payment history within the Payables Transaction History (PM30300) table for the selected calendar year range. It recalculates the 1099 amounts for each vendor based on these applied payments and updates the 1099 detail (PM00202) and summary (PM00204) tables. Manual edits made directly in the 1099 Details window (PM00202) are highly likely to be overwritten by the amounts derived from the transaction history (PM30300) when running the Calendar Year Reconcile.
  • Specific Credit Memo Scenario: If a credit memo was entered with a 1099 Amount but didn’t appear in the 1099 Details window, and you’ve manually updated the Credit1099Amount field in the PM30300 table (this is advanced data manipulation and should only be done with extreme caution and database backups, ideally by a GP professional), running the Calendar Year Reconcile should pick up this corrected historical record and update the 1099 details accordingly. Always verify if the document it was applied to also had a 1099 amount, as they may have netted each other out, which would be the correct result.

Reconcile processes are powerful data repair tools but should be used with caution, especially after manual data edits, as they can revert changes not supported by the underlying transaction history.

Additional Considerations

Beyond the direct causes and resolutions, a few other areas are worth checking when troubleshooting 1099 printing issues.

Ensure Latest Service Packs Are Applied

Microsoft frequently releases service packs and hotfixes for Dynamics GP. These updates often contain bug fixes, including those related to year-end processes like 1099 reporting. Ensuring your Dynamics GP installation is updated to the latest service pack for your specific version is crucial. Check the Microsoft Dynamics GP support pages for information on the current releases and their contents. Running on an outdated version might expose you to known issues that have already been resolved in later updates.

Run the 1099 Edit List Before Printing

Before printing official 1099 forms on pre-printed or plain paper, always run the 1099 Edit List report. This report shows exactly which vendors will have a 1099 printed and the amounts that will appear in each box. This is your opportunity to review the calculated 1099 data for accuracy before committing to printing forms that cannot easily be corrected. The edit list will immediately reveal if a vendor is missing or if their reported amount is incorrect, allowing you to troubleshoot using the steps above before the final print run.

To run the 1099 Edit List:
1. Navigate to Tools, point to Routines, point to Purchasing.
2. Select Print 1099.
3. Set the correct 1099 Year and 1099 Type.
4. Select any desired Vendor ID or Name ranges.
5. Choose the 1099 Edit List Report Type.
6. Click Print. Review this report meticulously.

Potential Data Corruption

In rare cases, underlying data inconsistencies or corruption within the Payables Management tables can cause 1099 data to be incorrect or prevent forms from printing. If none of the standard troubleshooting steps resolve the issue, and especially if other areas of Payables seem inconsistent, engaging a Dynamics GP partner with data repair expertise might be necessary to investigate potential data integrity issues.

Customized 1099 Reports

If your 1099 forms have been modified using Report Writer or other customization tools, it’s possible the issue lies within the custom report layout itself rather than the underlying data. Ensure you test printing using the standard Dynamics GP report layout to rule out customization problems. If the standard report prints correctly but the customized one doesn’t, the report customization needs to be reviewed and corrected.

Illustrating Data Flow for 1099s

Understanding how data moves through the system helps diagnose issues. Here’s a simplified flow:

```mermaid
graph LR
A[Vendor Setup
(Mark 1099able)] → B{Invoice Entry};
B – If Vendor 1099able → C[Invoice 1099 Amount Populated];
C – Post Invoice → D[PM Open Table];
D – Apply Payment
(Check/Credit Memo) → E[Payment Application
(Apply Date is Key)];
E – Creates History Record → F[PM History Table
(PM30300)];
F – Populates → G[1099 Detail Table
(PM00202)];
G – Summarizes to → H[1099 Summary Table
(PM00204)];
H – Used by → I{Print 1099
(Check against Minimum)};
I – If Amount >= Minimum → J[Print 1099 Form];
I – If Amount < Minimum → K[Do Not Print Form];
L[Update 1099 Utilities/PSTL] → G;
L → H;
M[Manual 1099 Details Edits] → G;

```

This diagram shows that the data starts with the vendor setup, flows through invoice entry, becomes reportable upon payment application (recorded in history), accumulates in the 1099 tables, and is finally evaluated against minimums for printing. Utilities and manual edits directly impact the 1099 tables (G, H).

Conclusion

Troubleshooting 1099 printing issues in Microsoft Dynamics GP involves checking a combination of vendor setup, transaction data, payment application dates, minimum thresholds, and system configuration. By systematically reviewing each of the potential causes outlined in this article, you can effectively diagnose why a vendor’s 1099 is not printing. Remember to always verify changes using the 1099 Edit List before printing final forms and consider running relevant reconcile processes or update utilities if historical data needs correction. Staying current with Dynamics GP service packs is also a vital preventative measure against known issues.

Do you have other troubleshooting tips for Dynamics GP 1099 printing? Have you encountered a scenario not covered here? Share your experiences and questions in the comments below!

Post a Comment