A cross-system vendor payment tie-out before 1099 filing

When a business acquires a second entity or changes accounting software mid-year, vendor payments can end up split between two ledgers. Each system produces a clean vendor list, but neither contains the full payment history. The team then tries to build 1099 totals from one export and misses payments recorded in the other. The gap is usually small until a vendor crosses the reporting threshold.

The problem is not only software. A shared services team may pay the same supplier from two bank accounts, and each account feeds a different ledger. A branch may keep a local payable list that never returns to the main system. The bookkeeper sees two reasonable reports that do not agree, so the quick fix is to choose one and move on. That choice hides the population the filing actually depends on.

Start by fixing the period and the source systems. Write down each ledger, bank account, and payment file that could contain a reportable vendor payment. Record the exact extraction date and the person who ran it, because a later export may include payments posted after the cutoff. Save the raw files without editing them, then work from copies so the original evidence stays intact.

Define the population in plain language before looking at totals. State whether the review covers payments, credits, reimbursements, or a combination, and name the calendar year that applies. Include voided and reversed payments for the reconciliation even when they will not appear on a form. The written definition lets two reviewers reach the same answer when a borderline vendor appears in only one system.

Build one vendor list from both systems and match records using the taxpayer identification number, legal name, and remit-to address. A name-only match fails when one system stores a trade name and the other stores the legal entity. Keep the original values beside the normalized values so the reviewer can see what changed. Mark each match as confirmed, probable, or unresolved, and write a short reason for the classification.

Do not merge a vendor pair just because the names look similar. Two related companies can share a parent name, a phone number, or an office address while remaining separate payees. Check the W-9, the contract, or the remittance instructions before treating the records as one vendor. If the identity is still unclear, leave the pair unresolved and show the payment exposure rather than forcing a clean total.

A payment ledger contains more than vendor compensation. Reimbursements, expense advances, rent, and certain card settlements may look like vendor payments in an export. Review the payment description, the general ledger account, and the supporting invoice before including an amount in the 1099 population. Keep an exclusion log with the vendor, amount, reason, and approver so the decision is reviewable later.

The exclusion log matters because the largest number is not automatically the correct number. A payment to a law firm may include filing fees that the firm paid on the client's behalf, and a payment to a contractor may include materials. The bookkeeper should not decide the tax treatment alone, but should separate the components and route the question to the tax preparer. The tie-out then shows both the gross payment and the amount under review.

After matching, add the included payments by vendor and compare the result with each ledger's payment total. Use the bank statements or payment processor reports as a third reference, especially when one system records payments from a feed. The reconciliation should explain every difference between the combined vendor total and the ledger control total. A difference that remains unexplained is a finding, not a rounding item.

Check the payment date rule consistently across both systems. One ledger may record the payment on the check date, while the other uses the settlement date, which can move a December payment into January. Apply one written rule and document any reclassification. The reviewer should be able to trace a single vendor total back to specific payment lines in both systems without rebuilding the entire spreadsheet.

Sort the exceptions by risk rather than by file order. Start with vendors near the reporting threshold, records with missing tax identifiers, and payments with conflicting addresses. Then review duplicate names, merged identities, and large one-off payments. Give each exception an owner and a due date, and keep the unresolved items visible until the tax preparer or client makes a decision. A silent exception becomes a filing error.

Reconfirm the vendor's legal name and tax identifier before the form is produced. The IRS instructions for Forms 1099-MISC and 1099-NEC tie the information return to the payee identity, so a merged total with the wrong name creates a new problem. A combined total is not complete until the identity behind it is confirmed by a document the reviewer can inspect. Use the vendor statement reconciliation to confirm that the payment history and the open balance still agree after the merge.

Close the work with a one-page summary that states the systems reviewed, the period, the population rule, the combined total, and every exclusion. Attach the raw exports, the matching table, the exception log, and the final vendor totals. List the reviewer's name and the date of approval. The summary should let someone reconstruct the total without opening a chat thread or asking the original bookkeeper.

Finally, store the package where the next filing season can find it. A short index with file names, versions, and the approval reference is enough. The close evidence room is a useful model because it keeps source files and review notes together. If the same vendor appears in both systems again next year, the tie-out becomes the starting map instead of a new investigation.