Contractor Payment Reporting — United States: TIN Matching, Vendor Payment Linking, Filing and Corrections (Odoo 19)

What it adds, and why that is what is missing

Linking starts from the payment, not the invoice. It is the mistake found in every spreadsheet: you total the year's invoices and report a contractor for a December invoice paid in February. The regime reports what was paid during the year. The module therefore starts from account.payment, and the payment method comes from the journal — a journal flagged as “payment card” produces a payment flagged as out of scope, with its reason, rather than silence.

Taxpayer identification number matching, and its workaround. The free module checks the format of an identifier. Knowing whether the name + identifier pair matches requires querying the tax authority — which allows it, “interactive or bulk”, but only through its portal, behind an account registered in the Payer Account File. No interface that software could call has been published.

So the module does not pretend. The “online service” source is wired and unchecked, with its reason written on screen. The workaround, on the other hand, really works: the batch generates the file, you upload it, you bring back the response file, and the module reads it. Each verdict carries its provenance — imported from a file, or entered manually — its date, and the service's raw code alongside, so that its interpretation remains open to challenge.

The filing file is driven by a column template. The exact specification expected by the portal could not be verified without an account. Writing an invented format would be the worst kind of false confirmation: the file would be generated, and rejected — or worse, accepted incorrectly. The module therefore ships a generic template, explicitly named as such, which you copy and align with what your filing agent requires. Available values are a closed list: a column cannot contain code.

Corrections start from what was filed. A correction is not an edit: it is a second filing that states what changes. The wizard copies the slips from the filed return — identity snapshot included — rather than starting again from the register, which may have changed for other reasons.

What it does not do, and says so

• It transmits nothing to the authorities. It produces the files; you file them.

• It does not place a correction in an official category: those rules could not be verified at the source, and it does not invent them.

• It draws no conclusions. It states that a name–identifier pair did not match, on a given date, from a given source. It does not say whether the payment should be withheld.

Not proven in production. No actual filing and no actual batch has been submitted to a government authority using this module. Everything that could not be verified is written in VERIFICATION.md and displayed on screen, never guessed.