Amazon Vendor Remittance: How to Match Each Payment to Its Invoices and Deductions

A vendor invoices Amazon purchase order by purchase order, and Amazon pays in lump sums. One payment can cover dozens of invoices, less early payment discounts, deductions, returns and advertising, and the bank statement shows only the total. For a brand that sells to Amazon at wholesale, which is how Vendor Central differs from Seller Central, matching that total back to the invoices is a monthly job that rarely closes cleanly.

It has also been a manual one. In January 2023 a developer asked, on the GitHub discussions Amazon runs for its Selling Partner API, how to get vendor payment data, and an Amazon solutions architect answered: "Currently we don't have any api's for vendor payments information for invoices and remittances." On 30 September 2026 Amazon launched the Finance Remittance API, "which you can use to programmatically retrieve vendor payment remittance data." This is what a remittance contains in Amazon's own terms, why a payment comes up short, and the reconciliation we run.

Amazon's documentation says the API returns the same data as the Remittance view under Payments in Vendor Central, so that a vendor can retrieve its cash flow breakdown, "including invoice payments, deductions, vendor returns, and advertising". Every remittance has two levels.

The payment. A header with the payment date, the amount, the payment method, a payment number and a unique payment ID. Amazon's tutorial warns that the unique payment ID "is different from the payment number." The payment number is the external reference, the one to look for on the bank statement. Each payment also carries one of three statuses: in progress, successful or failed.

The lines. One for each invoice the payment touches, with the invoice number and issue date, the payment terms, the invoice type, a description, the total amount (split into the invoice amount and the tax) and the net amount paid (split into the amount paid and any terms discount taken).

The terms discount is the line finance teams expect and still miss. Amazon defines it as "The discount applied based on vendor payment terms", and gives an example: "early payment terms such as 1% 30, NET 60 allow a percentage discount on the invoice value when payment is made within the specified period." If the terms agreed with Amazon include an early payment discount, this is where it is taken.

The gap between invoiced and paid has five usual sources.

Terms discounts, on the line of each invoice paid inside the discount period.

Deductions. Amazon's documentation names them without listing their types. As vendors and the recovery tools that work on these accounts describe them, the common ones are shortage claims, for units invoiced that Amazon records as not received; operational chargebacks, for shipments that missed a delivery window or the routing and labelling requirements; the co-op and marketing allowances agreed in the annual terms; price protection; and damage allowances. They report that each arrives with a reference code rather than an explanation.

Vendor returns, which Amazon lists as a category of their own: stock sent back to the vendor, charged against what Amazon owes.

Advertising. Amazon Ads can be paid from the vendor account balance. In April 2026 Amazon called account balance payments "the payment method used by the overwhelming majority of our advertisers", in which "debits and credits are handled automatically." For a vendor paying that way, the month's advertising spend comes out of the retail payments, and the marketing budget meets the receivables on the same remittance.

Partial payment. Amazon's tutorial is plain that "A single invoice can be paid or deducted across multiple payments." An invoice that looks underpaid on one remittance may be finished on the next, so it is closed when the lines across every payment add up, not when the first one arrives.

A missing invoice is a different problem from a short one, and Amazon's invoicing documentation explains most of them. "Items must be invoiced only after they are confirmed and shipped to Amazon. Otherwise, the invoice is rejected." The payment terms on an invoice "must match the payment terms agreed upon with the Amazon buyer." The remit-to address "must match the address that Amazon has on file. If the address doesn't match, the invoice fails." And "When you submit incorrect invoice data through either Vendor Central or the API, Amazon cancels the invoice."

Two more catch people out. "An invoice can be successfully submitted, then rejected", with the reason sent by email, so a clean submission is not proof the invoice reached Amazon's payee system. And "Invoice numbers must be unique and must never be reused", so a corrected invoice goes in under a new number. The price is fixed earlier still: the cost on a purchase order acknowledgement has to match the invoice, one of the details behind reading Amazon's purchase orders correctly.

The data is not new. What changed is that a system can now read it instead of a person exporting it. Amazon's tutorial sets out the workflow: list the payments for a store and date range, "Match each payment against your bank statement", then retrieve each payment's invoice lines and match them to the accounting system by invoice number. The net amounts across the lines then reconcile to the payment, "giving you a complete audit trail from bank statement to invoice". It suggests a daily job for the previous day's payments, or a monthly one for month-end close.

Three limits shape the build. Remittance data is available from 1 January 2024 onward, so close to three years can be backfilled. Each request covers at most 90 days. And the application needs the Finance and Accounting role, which Amazon describes as access to "operations that create accounting and financial statements". Whoever builds it, a developer or an accounting tool, gets that role and nothing broader.

Our practice, monthly at the least and weekly for a vendor with volume.

Bank to payment. Each deposit matched to one payment by payment number, amount and date. A deposit with no payment, or a payment that is not yet successful, is the first question.

Payment to lines. If the lines' net amounts do not add up to the payment, the pull is incomplete, and nothing below it can be trusted yet.

Lines to invoices. Invoiced against net paid, by invoice number. The difference is a terms discount, a partial payment still to come, or a deduction.

Deductions sorted by type. Each one coded as shortage, chargeback, co-op, price protection, damage or return, then checked against the agreed terms and the shipping records. Vendors report that each type has its own dispute window inside Vendor Central, so the sorting cannot wait for the quarter end.

Disputes with evidence. A shortage is disputed with the proof of delivery and the carton contents, a chargeback with the shipment's own records. The case is built like support cases that actually get resolved: one claim, the evidence attached, the outcome asked for. Getting back money that should never have been taken is the same discipline as our cost recovery work for sellers.

Invoices with no line. Anything invoiced and absent from every remittance past its due date is checked for rejection or cancellation before it is chased as late.

Reconciling remittances, disputing the deductions that do not hold up and fixing the invoicing that leaves money unpaid is part of how we run Amazon Vendor Central for brands Amazon buys from. If payments and invoices have stopped matching, the deductions are where we would start.