Amazon Insurance Requirements: An Operator's Guide 2026

Monthly revenue crosses a line item that looked harmless in last week's dashboard. Then a compliance message shows up, support threads get noisy, and the operator has to answer a very specific question fast: does the account now need insurance on file, and if so, what exactly has to be submitted?

Here's the practical reality of Amazon insurance requirements. It rarely starts as a legal research project. It starts as an operational interruption tied to revenue velocity, account health, and document quality. The hard part usually isn't buying a policy. The hard part is proving that the policy, the certificate, and the account record all line up with Amazon's validation rules.

Operators who already monitor account notifications know this pattern. A message that looks administrative can become account risk if it sits untouched in the queue. Teams that already review Amazon messages in a repeatable workflow usually catch insurance issues earlier because they treat compliance events like production events, not inbox clutter.

Table of Contents

• Introduction The Insurance Compliance Trigger
• Determining if You Need Amazon Seller Insurance
  • The trigger
  • How to verify status from operating data
• Required Policy Types and Coverage Minimums
  • What policy format qualifies
  • What to confirm before binding
• The Certificate of Insurance COI Decoded
  • COI field requirements for Amazon
  • What operators should validate before upload
• Submitting and Verifying Your COI in Seller Central
  • The submission workflow
  • What to check if Amazon rejects it
• Automating Compliance Monitoring with agentcentral
  • Treat compliance as a monitored state
  • A practical monitoring workflow
• Consequences of Non-Compliance and Common Pitfalls
  • Where accounts usually fail
  • Why Relay creates confusion
• Amazon Seller Insurance FAQs
  • Do small sellers need to buy insurance before Amazon asks
  • Does one Amazon insurance policy cover selling and hauling
  • What should a broker receive from the operator
  • What if the policy is valid but the certificate is rejected
  • Does product category change the compliance process

Introduction The Insurance Compliance Trigger

A seller finishes month-end reconciliation, sees a sales spike, and assumes the compliance team can sort out insurance later. Then Amazon requests proof of coverage, and the complex task begins. Someone has to confirm whether the threshold event was recorded, who owns the response window, whether the policy is already in force, and whether the Certificate of Insurance matches the account data Amazon has on file.

That is the trigger that matters operationally. A revenue event turns into a document control event, and delays usually come from workflow gaps, not from confusion about what insurance is supposed to do.

For this reason, Amazon insurance requirements should be treated as an operational state. The account can be below threshold, under review, waiting for a COI, approved, rejected, or exposed because a renewal, named insured field, or cancellation notice no longer aligns with Amazon's record. Each state needs a timestamp, an owner, and a system of record.

I treat this as a monitoring problem first. The inputs are concrete: monthly gross sales status, Amazon request date, policy effective date, expiration date, carrier, limits, named insured, and COI version. The workflow should be just as concrete: detect the trigger, open the task, collect the document, validate the fields, submit, confirm acceptance, and keep watching for drift after approval.

One missed message can break that chain. Teams that do not have a clean intake process should also review how to check Amazon account messages tied to compliance requests, because the deadline risk often starts with a notice that was never routed to the right owner.

The common failure point is not the concept. It is one exact field, one stale certificate, or one policy change that no one logged. That is why a structured data layer such as agentcentral matters. It turns insurance compliance from a one-time upload into a monitored, auditable operating state.

Determining if You Need Amazon Seller Insurance

The trigger

A seller can go from compliant to exposed in one strong month. The operational question is simple: did gross monthly sales on Amazon.com cross Amazon's insurance threshold, and if so, when did that happen?

As noted earlier, Amazon ties the requirement to monthly gross sales on Amazon.com, not to an annual projection or a general sense that the business is growing. Amazon also shifted from an older multi-month test to a single-month threshold. That change matters because one promotion, one seasonal peak, or one catalog expansion can create a compliance event even if prior months were lower.

For operations teams, this should be tracked as a state change in the account record. Once the threshold is crossed, the team needs a dated trigger event, a named owner, and a document workflow that starts immediately. If that handoff is informal, the account usually loses time between finance, account management, and the broker.

How to verify status from operating data

The cleanest process uses one source of truth for sales status and one source of truth for insurance documents. Do not rely on settlement summaries or payout views to answer a compliance question. Those views are built for reconciliation, not for proving whether a monthly gross sales trigger occurred.

Use a repeatable check:

1. Pull Amazon.com sales for the relevant monthly period. Use Seller Central reporting or SP-API outputs that map to marketplace and month.
2. Read gross sales as gross sales. Do not net out refunds, chargebacks, or reimbursement timing unless your internal reporting clearly preserves the original gross figure Amazon would evaluate.
3. Record the trigger date. Store the month, the date the threshold was confirmed internally, and the date Amazon requested proof if a notice has already been issued.
4. Assign a workflow owner. In practice, this belongs to account operations with a clear dependency on broker response time and document review.
5. Open a compliance record. Track status, policy request date, COI receipt date, submission date, and review outcome in one place.

That record is what turns a threshold check into an auditable process.

A practical internal status model often looks like this:

The trade-off is speed versus accuracy. Teams that rush to purchase coverage without confirming the trigger date or without logging the policy details often create a second problem later, especially when renewal dates, named insured fields, or COI versions no longer match what Amazon has on file.

Threshold detection should sit inside compliance operations, with finance data as an input. If no one owns that state change, the account is relying on luck.

Required Policy Types and Coverage Minimums

What policy format qualifies

A seller can have an active liability policy, a paid premium, and still fail Amazon review because the policy form does not match the platform requirement. The control point is not just "insured or uninsured." It is whether the policy record meets Amazon's accepted structure. Amazon generally expects at least $1 million per occurrence and accepts commercial general liability, umbrella, or excess liability coverage written on an occurrence basis, with products liability included and a carrier meeting the stated financial strength standard, as summarized in this seller insurance requirements reference.

For compliance operations, occurrence basis is the field that deserves explicit validation. A claims-made policy can be legitimate insurance, but that does not make it a clean fit for Amazon's stated requirement. The review workflow should capture policy form, liability class, limits, and carrier rating as separate data points, not as a single "insurance on file" checkbox.

The practical distinction is straightforward:

• Occurrence basis: coverage responds based on when the incident happened during the policy period.
• Claims-made: coverage depends more heavily on when the claim is reported and how the reporting terms are structured.

Operators should therefore not ask a broker for "Amazon insurance" in broad terms. The request should specify the exact policy class, occurrence form, products liability inclusion, limit structure, and certificate requirements. That reduces the chance of receiving a document package that looks complete in email but fails review in Seller Central.

What to confirm before binding

Before binding, treat the quote and draft certificate as a pre-submission data check.

Validate these fields against the account's compliance record:

• Coverage limit: Confirm the policy meets the $1 million per occurrence requirement.
• Policy type: Confirm the quoted form is commercial general liability, umbrella, or excess liability, and that the structure aligns with Amazon's criteria.
• Coverage basis: Verify the policy is written on an occurrence basis.
• Products liability: Confirm products liability is included, not assumed.
• Carrier rating: Verify the insurer meets the required financial strength threshold.
• Additional insured handling: Confirm the policy and certificate workflow can add Amazon and its affiliates or assignees as required.
• Entity match: Check that the insured legal entity matches the seller account records before documents are issued.

Teams frequently create preventable rework. They bind first, then discover the named insured is wrong, the certificate request was incomplete, or the policy form does not align with Amazon's review criteria.

A policy that fails document review creates the same operational result as having no acceptable policy on file.

The better operating model is continuous validation. Store the policy type, occurrence indicator, limit, carrier name, rating, effective date, expiration date, additional insured status, and COI version in a structured compliance layer such as agentcentral. Once those fields are tracked as live records instead of static attachments, renewal monitoring and exception handling become auditable tasks rather than inbox cleanup.

The Certificate of Insurance COI Decoded

A seller can have a valid policy in force and still fail Amazon review because the COI is wrong. That usually happens in a simple operational sequence. The broker issues the certificate from an intake email, the seller uploads the PDF, and no one compares the certificate fields against the Seller Central account record or the policy declarations before submission.

The COI is the review artifact Amazon sees first. Treat it as a controlled data record, not just a file export. The practical question is not whether coverage exists in the abstract. The question is whether the certificate presents the exact fields, names, dates, and endorsements in a form Amazon can validate against the seller account.

COI field requirements for Amazon

A useful review method is to break the certificate into auditable fields and assign an owner to each check. In operations teams I have worked with, that means the account owner confirms the legal entity, the broker confirms certificate wording, and the compliance operator reconciles the COI against the declarations page and the Seller Central profile before upload.

The notice language is a frequent failure point because the policy may be acceptable while the certificate text is not. Certificate reviewers should check the wording on the actual issued COI, not assume the broker request was implemented.

That is why the COI should live in a structured compliance layer with version control. Store COI version, issue date, named insured, policy number, effective date, expiration date, carrier, additional insured status, and notice wording status as discrete fields. A team that wants fewer resubmissions can route those fields through a pre-submit checklist or an automated review flow, such as connecting Amazon Seller Central to Claude through agentcentral, before anyone uploads the PDF.

What operators should validate before upload

Broker instruction quality determines certificate quality. A short request like "please send a COI for Amazon" leaves too much room for interpretation. A controlled request package should include the seller's exact legal entity name, the policy identifier, the required Amazon entity wording for additional insured handling, the certificate holder details, and the notice wording your team expects to see on the issued form.

Use the COI and the declarations page together. The certificate is a summary document. The declarations page is the source record for policy number, dates, named insured, and limits. If those two documents do not reconcile line by line, stop the workflow and correct the source data before submission.

A clean PDF is not evidence of compliance. A reconciled certificate is.

This is also where continuous monitoring matters more than one-time document collection. Certificates expire, entities change, brokers reissue forms, and renewal terms shift. If the COI is tracked only in email and shared folders, those changes surface late. If the COI fields are stored as live records in agentcentral, every reissue becomes an auditable event with timestamps, owner assignment, and exception handling.

Submitting and Verifying Your COI in Seller Central

The submission workflow

Once the policy and certificate package are aligned, the upload step should be handled like a controlled release. The operator enters the insurance area in Seller Central, provides insurer information, and uploads the COI document. The exact page labels can shift, but the process is still the same: input structured insurer data, attach the document, and submit for review.

Before clicking submit, it helps to run one final internal comparison against the account record:

• Entity name: Must match Seller Central exactly.
• Document readability: Blurry scans and incomplete pages slow review.
• Certificate dates: Active term should be visible and consistent.
• Amazon-specific language: The notice requirement and additional insured handling should already be present.

This is also where documentation discipline matters. Teams using shared folders without naming standards often lose the approved version and accidentally upload an earlier draft.

What to check if Amazon rejects it

Verification can take time, and a rejection doesn't always mean the policy itself is wrong. It often means the submission package is incomplete or the certificate wording doesn't satisfy review.

A clean rejection workflow usually looks like this:

1. Read the account notification carefully. Don't rely on memory of what was uploaded.
2. Compare the rejected file with the broker's final approved version. Teams sometimes upload the wrong attachment.
3. Check required fields first. Entity name, effective dates, additional insured wording, and cancellation notice language are the usual failure points.
4. Request a revised COI, not a policy rewrite, if the issue is certificate formatting.

Operators managing Seller Central access through external workflows often benefit from keeping the submission path documented alongside their broader account connection procedures. A practical reference for that setup discipline is this guide to connecting Amazon Seller Central to Claude, because the same principle applies: exact permissions, exact fields, and no ambiguity about which system holds the current source of truth.

Automating Compliance Monitoring with agentcentral

Treat compliance as a monitored state

Insurance compliance breaks when teams treat it as a one-time admin task. The requirement may begin after a sales event, but the operational burden continues after approval. Policies expire. Renewals arrive with revised certificates. Seller support messages surface warnings at inconvenient times. Ownership gets fuzzy when one person handled the original upload and another person now owns account health.

A better model is to store compliance as structured state with explicit checks:

A structured data layer offers greater utility than a spreadsheet. The goal isn't recommendation. The goal is deterministic reads, repeatable checks, and auditability across systems that otherwise drift apart.

A practical monitoring workflow

A practical MCP-enabled workflow can monitor insurance without turning the process into a custom engineering project:

• Sales threshold watch: Run a scheduled read against gross sales and flag the account when the monitored month crosses the internal threshold rule used for compliance tracking.
• Document lifecycle watch: Store policy effective and expiration data as structured metadata tied to the seller account.
• Notification watch: Poll performance and account notifications for insurance-related requests or rejection messages.
• Escalation routing: Send an alert to operations when the account enters a risk state such as threshold crossed, renewal due, or submission rejected.

The important design choice is separation of responsibilities. The data layer should return the facts. The workflow or agent should decide what notification to send. That keeps the compliance pipeline inspectable.

For teams building these checks into broader Seller Central operations, Amazon Seller Central tools used in MCP workflows are most effective when reads are fast, repeated access is stable, and every write or alert has an audit trail.

Compliance automation works best when every state change has an observable input, a timestamp, and a human owner.

An operator shouldn't have to ask, “Did someone renew the policy?” The system should be able to answer, “Renewal document received, pending review,” or “No updated COI on file, account at risk.”

Consequences of Non-Compliance and Common Pitfalls

Where accounts usually fail

Amazon insurance requirements create business risk when the account crosses into a required state and no one closes the loop. The practical consequences can include interruption to selling operations, delayed resolution cycles, and unnecessary back-and-forth with brokers and account staff.

The biggest pitfalls are usually procedural, not conceptual:

• Wrong policy basis: Teams buy a policy format that doesn't meet Amazon's stated standard.
• Weak document control: The broker issues a corrected COI, but the seller uploads an older file.
• Lapsed renewal handling: The original compliance task gets completed, then no one tracks expiration.
• Entity mismatch: The selling entity, policy named insured, and Seller Central legal record don't align.
• Missing cancellation notice language: The certificate looks complete but fails a required clause check.

A surprising number of failures happen because operations and finance use different source records. Finance tracks premium payment. Operations needs an accepted COI in Seller Central. Those are not the same checkpoint.

Why Relay creates confusion

Some sellers search for Amazon insurance requirements and land on Relay information. That's where category confusion starts. Relay is a freight carrier program with a different insurance stack and a different risk model.

For Amazon Relay carriers, the required stack includes $1 million auto liability per occurrence, $100,000 cargo coverage, $1 million commercial general liability per occurrence with $2 million aggregate, plus workers' compensation where applicable and $100,000 employer's liability, with DOT authority active for at least 180 days, according to Amazon Relay's FAQ. The same Relay guidance also notes that newer carriers often pay $12,000 to $18,000 annually for required coverage, while experienced carriers with cleaner records often pay $8,000 to $14,000.

That distinction matters. Seller Central compliance and Relay carrier onboarding are different programs. Treating them as one rule set leads to the wrong broker request, the wrong certificate assumptions, and the wrong operational checklist.

Amazon Seller Insurance FAQs

Do small sellers need to buy insurance before Amazon asks

A common operating mistake is treating insurance as complete only when Amazon triggers the requirement. That works for a narrow moment in time, but it creates avoidable delay once the account crosses the threshold and Seller Central expects a valid certificate.

Some sellers place coverage earlier because the actual workflow is not just buying a policy. It is collecting the legal entity name, confirming the insured matches the Seller Central record, getting the COI issued with the required fields, and keeping that document current. If Amazon has not triggered the requirement yet, early placement is a risk and readiness decision rather than a platform document requirement.

Does one Amazon insurance policy cover selling and hauling

Seller Central and Amazon Relay should be handled as separate compliance tracks.

A seller account may need commercial general liability support for marketplace compliance. A carrier operating in Relay faces a different insurance stack tied to freight operations. Teams get into trouble when they send a broker a vague request for "Amazon insurance" and assume one certificate can satisfy both programs.

As noted earlier, Seller Central also checks for specific certificate language and entity alignment. Relay requirements do not replace that review.

What should a broker receive from the operator

Send a structured request, not a casual email.

At minimum, give the broker the exact legal name of the selling entity, the business address on the Seller Central account, the requested coverage type, the certificate holder details Amazon expects, and any wording Amazon requires on the COI. Ask for the draft certificate before final issuance so operations can compare field values against the Seller Central legal record.

That review step cuts down rework. In practice, the failed submissions I see usually trace back to mismatched entity data, missing wording, or a certificate produced from stale account records.

What if the policy is valid but the certificate is rejected

Treat the rejection as a data quality problem first.

The policy may be active while the COI still fails review because the named insured is formatted differently, the address does not match, the cancellation clause is incomplete, or the certificate omits a field Amazon expects to see stated clearly. The fix is usually to reconcile three records line by line: the policy declarations, the COI, and the Seller Central account details.

This is also where operational monitoring matters. A valid policy does not guarantee a compliant account state if the wrong certificate version was uploaded or the accepted document later expires.

Does product category change the compliance process

Product category can change underwriting questions and pricing. It does not change the need for clean compliance operations inside Seller Central.

The repeatable process stays the same: detect when the account enters a required state, confirm the policy meets the account's needs, submit a COI that matches Amazon's record requirements, and monitor for changes that can break compliance later. Teams that store those checkpoints in a structured system have fewer surprises than teams relying on inbox searches and broker PDFs.

agentcentral gives Amazon operators and developers a structured data layer for the workflows around account compliance, sales monitoring, notifications, and auditability. Instead of treating Seller Central as a set of manual screens, teams can connect seller data to MCP clients with scoped access, fast repeated reads, and logged actions that make operational state easier to monitor. For teams building monitored workflows around Amazon accounts, agentcentral is designed to provide the facts and system inputs that agents or internal automations can act on.