US sales-tax filing
Pull GET_FLAT_FILE_SALES_TAX_DATA daily to reconcile tax collected per jurisdiction and prepare state and local sales-tax returns.
E-commerce · Amazon SP-API · Restricted role
Tax Remittance (Restricted) role
The Tax Remittance (Restricted) role unlocks the SP-API operations and reports used to calculate and remit sales taxes, the US sales-tax flat file, the India GST merchant tax reports, and the Orders data that pins each sale to a jurisdiction. Because those operations might use buyer PII to compute tax, Amazon gates the role behind a compliance review. It does not score how good your software is. It scores your file.
GET_FLAT_FILE_SALES_TAX_DATA
GST_MTR reports (IN)
Orders API v0
Buyer PII
Amazon does not approve a Tax Remittance application because it is well written. It approves because the application demonstrates compliance.
This role reads tax-relevant buyer PII, ship-to location, names, company and tax IDs. The reviewer wants to see exactly why you need it, and proof you will protect it. That is the file we rebuild.
40+
developer & restricted-role accesses since 2018
87%
of our customers got the access they applied for (since 2018)
48h
to deliver your complete compliance file
4
tax report types this role gates
What the role is
What the Tax Remittance role covers
It is the SP-API permission that authorizes the operations behind sales-tax calculation and remittance. Get the definition right, because it decides which reports and operations you can request, and which you cannot.
Amazon's official definition
Per Amazon's roles documentation, the role is defined verbatim as: "The Tax Remittance (Restricted) role provides access to operations that calculate and remit sales taxes. Operations that require this role might use PII to calculate sales taxes."
Note the precise wording, operations might use PII. That is what distinguishes it from its sibling, Tax Invoicing (Restricted), which covers operations that generate tax invoices to comply with tax regulation and require PII. Tax Remittance is about computing and remitting tax; Tax Invoicing is about producing legal invoices. They gate different reports and must each be justified on their own terms, do not conflate the two on your application.
The role gates two families of access: the SP-API tax reports requested through the Reports API, and a set of Orders API v0 operations that return the order, buyer and ship-to data a tax engine needs to determine the correct jurisdiction and rate.
A role is only as useful as the operations it unlocks.
Here is exactly what the Tax Remittance role lets your software call.
The API in practice
The reports & operations this role gates
Two paths give you tax data: pulling the dedicated tax reports, and reading live order data. Both accept Tax Remittance (Restricted). The technical names below are reproduced verbatim, do not alter them on your application.
Tax reports, Reports API v2021-06-30
Four report types list Tax Remittance (Restricted) as the required role. You request them with createReport, then retrieve them with getReport and getReportDocument.
- GET_FLAT_FILE_SALES_TAX_DATA (US), a tab-delimited flat file for tax-enabled US sellers, content updated daily. The core report for reconciling US sales tax by jurisdiction.
- GST_MTR_B2B (India), detailed sales, refunds and cancellations from Amazon Business invoices issued within a date range you specify.
- GST_MTR_B2C (India), detailed sales, refunds and cancellations from consumer invoices issued within a date range you specify.
- GST_MTR_STOCK_TRANSFER_REPORT (India), details on inventory movements from Amazon Fulfillment Centers (FC removals or FC-to-FC transfers).
Keep the VAT reports out of a Tax Remittance application: SC_VAT_TAX_REPORT, GET_VAT_TRANSACTION_DATA and the *_CUSTOM GST reports require Tax Invoicing (Restricted), not this role, requesting the wrong role for the data you need is a common reason an application stalls.
Live order data, Orders API v0
Per the Orders API v0 use case guide, Tax Remittance (Restricted) is one of the accepted roles for these operations:
- getOrders: retrieves orders created or updated in a date range.
- getOrder: retrieves a single order by AmazonOrderId.
- getOrderItems: retrieves the line items of an order (quantity, ASIN/SKU, item price and tax, promotions).
- getOrderItemsBuyerInfo: buyer-specific information at the item level, such as gift wrap or message and buyer-paid item tax.
- getOrderAddress: retrieves the ship-to address for an order, used to determine the tax jurisdiction.
- getOrderBuyerInfo: buyer-level information for an order, such as buyer email, buyer name and buyer tax info.
These are restricted operations. Even with the role granted to your app, each live call must be authorized with a Restricted Data Token (RDT) obtained from the Tokens API via createRestrictedDataToken. The role is necessary but not sufficient, the RDT is what actually unlocks each restricted Orders call.
Why does Amazon wrap a tax role in a security review at all?
Because tax is computed against where the buyer is, and that is personal data.
The data it unlocks
The buyer data it unlocks, and why Amazon gates it
Tax must be calculated to the ship-to jurisdiction, so location data is intrinsic to the role. That is exactly why it is classified (Restricted) and why your file has to prove you handle the data correctly.
- Buyer location data: city, state/province, postal/ZIP code and country (from getOrderAddress and the US sales-tax report), used to determine the tax jurisdiction and rate.
- Buyer identity and company: buyer name and, for B2B, business or company name and tax registration numbers such as a GSTIN in India, appearing in the GST merchant tax reports and the order buyer-info operations.
- Transaction-level tax detail: item price, tax collected, tax rate, refunds, cancellations and invoice values.
Amazon's own wording is the reason it is restricted: operations that require this role "might use PII to calculate sales taxes." That is why the live Orders operations demand a Restricted Data Token (RDT). The four Tax Remittance report types, by contrast, are not flagged as restricted-report RDT cases at the getReportDocument step, unlike the VAT reports, which explicitly require an RDT there. Your application has to show you read only the PII you need, scope it tightly, and delete it on time.
Not every tool needs this role, and asking for it without a fit is a fast way to a refusal.
Here is who genuinely needs Tax Remittance, and who does not.
Use cases
Who needs the Tax Remittance role
Concrete, tax-driven workflows, the kind of justification Amazon expects to see tied to each report and operation you request.
Marketplace Facilitator reconciliation
Separate tax Amazon remitted as marketplace facilitator from seller-liable tax, by jurisdiction, for your accountants.
India GST compliance
Pull GST_MTR_B2B, GST_MTR_B2C and GST_MTR_STOCK_TRANSFER_REPORT to file GST returns, reconcile B2B versus B2C invoices and account for FC-to-FC and removal stock movements.
Tax-engine & nexus
Feed order ship-to addresses from getOrderAddress into a tax-calculation engine to determine nexus and rates by jurisdiction.
ERP & accounting posting
Post tax-aware transactions into ERP and accounting systems with the per-jurisdiction tax detail your finance team needs.
Audit trails
Maintain jurisdiction-level transaction records to support tax-authority audits and defend your filings.
Who needs it: sales-tax and use-tax automation software; VAT/GST filing platforms; ERP and accounting integrators; OMS and financial-reconciliation tools computing per-jurisdiction liability; and multi-channel sellers or aggregators filing across many US states or running FBA in India.
Who does not: pure listing, inventory, pricing or buyer-messaging tools do not typically need Tax Remittance, and requesting it without a tax use case invites a refusal. If you produce legal invoices rather than compute remittance, you likely need Tax Invoicing (Restricted) instead.
You know the role, the reports and the data. The only thing standing between you and access is the file.
And the file is exactly where most applications fail.
How to get approved
How to get the Tax Remittance role approved
A restricted-role review is a data-protection assessment. We align your file to every control Amazon scores and tell you, in plain language, what to have in place, without ever touching your systems.
1. A role justification that fits. A clear, tax-specific reason you need Tax Remittance (Restricted), which reports and Orders operations you call, and why computing or remitting tax requires the location and tax-ID data they return. We map your request to Amazon's official role definition so the reviewer sees an exact fit.
2. A field-level data inventory. Which PII you read (ship-to address, buyer name, company, tax IDs), where it flows, how it is scoped, and that you obtain a Restricted Data Token for each restricted Orders call rather than over-collecting.
3. A publishable Data Handling & Privacy Policy. A ready-to-publish page covering collection, processing, storage, use, sharing and disposal, one of the two things Amazon checks for a private app.
4. An implementation checklist. Every control in plain language: TLS 1.2+ in transit and AES-128+ at rest with a KMS and key rotation, PII deleted no later than 30 days after delivery, PII-free logs retained 12+ months, least-privilege access with MFA, and Login with Amazon only, never stored Seller Central credentials.
Amazon rarely tells you what went wrong. The decision almost always comes back as one line: "security and compliance documentation did not meet requirements."
That single line is exactly what we rebuild.
The real reason
Why Tax Remittance applications get rejected
Almost never because of the product. Almost always because of the file. For a tax role, these are the issues that surface most:
- Requesting the wrong role, asking for Tax Remittance when you actually generate invoices (that is Tax Invoicing), or vice versa.
- Weak justification for why computing or remitting tax requires the location and tax-ID PII you request.
- No field-level data inventory showing which PII is used, where and why.
- PII retention not capped or not provably automated, no enforced 30-day deletion after delivery.
- Logs that store customer PII, or no evidence of access reviews and offboarding.
- No RDT handling described for the restricted Orders operations this role gates.
- Documentary inconsistency, the answers, the privacy policy and the security procedures contradict each other.
- Generic, copy-paste answers and vague wording that prove nothing.
- Any hint of credential harvesting, asking for Seller Central passwords or keys is an automatic refusal.
- Any hint of cross-seller data aggregation or resale of Amazon-derived tax data.
Amazon reviews evidence, not promises. We remove every one of these reasons, so there is no compliance ground left to refuse you on.
Tax Remittance (Restricted), frequently asked questions
What does the Amazon SP-API Tax Remittance (Restricted) role do?
Per Amazon's roles documentation, the Tax Remittance (Restricted) role "provides access to operations that calculate and remit sales taxes. Operations that require this role might use PII to calculate sales taxes." In practice it gates the SP-API sales-tax reports and the Orders operations a tax engine reads to determine the right jurisdiction and rate.
Is Tax Remittance the same as Tax Invoicing (Restricted)?
No, and conflating them is a common mistake. Tax Remittance (Restricted) covers operations that calculate and remit sales taxes and might use PII. Tax Invoicing (Restricted) covers operations that generate tax invoices to comply with tax regulation and require PII. They gate different reports, so each must be requested and justified on its own terms, do not request one when you need the other.
Which reports require the Tax Remittance (Restricted) role?
Four report types list Tax Remittance (Restricted) as the required role: GET_FLAT_FILE_SALES_TAX_DATA (US, a tab-delimited flat file for tax-enabled US sellers, content updated daily), and three India GST reports: GST_MTR_B2B, GST_MTR_B2C, and GST_MTR_STOCK_TRANSFER_REPORT. The VAT reports (SC_VAT_TAX_REPORT, GET_VAT_TRANSACTION_DATA) and the *_CUSTOM GST reports belong to Tax Invoicing, not Tax Remittance.
Which Orders API operations accept the Tax Remittance role?
Per the Orders API v0 use case guide, Tax Remittance (Restricted) is one of the accepted roles for getOrders, getOrder, getOrderItems, getOrderItemsBuyerInfo, getOrderAddress and getOrderBuyerInfo. These return order, item, buyer and ship-to address data used to compute tax to the correct jurisdiction.
Do I need a Restricted Data Token (RDT) for this role?
Yes, for the live Orders operations. Those are restricted operations: even with the role granted to your app, each call must be authorized with a Restricted Data Token obtained from the Tokens API via createRestrictedDataToken. The four Tax Remittance report types are not flagged as restricted-report RDT cases at the getReportDocument step, unlike the VAT reports, which do require an RDT there.
What buyer data does the Tax Remittance role unlock, and why is it restricted?
It can surface buyer PII used to determine tax: ship-to location (city, state/province, postal/ZIP, country), buyer name, and, for B2B, business/company name and tax registration numbers such as a GSTIN in India, plus transaction-level tax detail (item price, tax collected, rate, refunds, cancellations). Amazon's docs state operations that require this role "might use PII to calculate sales taxes," which is why it carries the (Restricted) classification and an RDT requirement for live order operations.
Does the Tax Remittance role apply outside the US?
Yes. The US sales-tax report GET_FLAT_FILE_SALES_TAX_DATA is US-only, but the role also gates three India GST reports, GST_MTR_B2B, GST_MTR_B2C and GST_MTR_STOCK_TRANSFER_REPORT, used to file GST returns and reconcile B2B versus B2C invoices and FC-to-FC stock movements.
Who needs the Tax Remittance (Restricted) role?
Sales-tax and use-tax automation software, VAT/GST filing platforms, ERP and accounting integrators that post tax-aware transactions, OMS and financial-reconciliation tools computing per-jurisdiction liability, and multi-channel sellers or aggregators filing across many US states or running FBA in India. It is not typically needed by pure listing, inventory, pricing or buyer-messaging tools.
Can the Tax Remittance role create a Restricted Data Token?
Yes. Tax Remittance (Restricted) is among the roles authorized to call createRestrictedDataToken in the Tokens API. The role is necessary but not sufficient: you still need the role granted to your app and a valid RDT scoped to each restricted Orders call.
Why do Tax Remittance applications get rejected?
Almost never because of the product, almost always because of the file. Amazon's most common rejection is that your security and compliance documentation did not meet requirements: a weak justification for why you need tax-relevant PII, no field-level data inventory, PII retention that is not capped or provably automated, logs storing PII, or contradictions between the application answers, the privacy policy and the security procedures. Amazon reviews evidence, not promises.
How do I get the Tax Remittance (Restricted) role approved?
You remove every compliance reason to refuse you: a precise role justification tied to calculating and remitting tax, a field-level data inventory of the location and tax-ID PII you read, a publishable Data Handling & Privacy Policy, and an implementation checklist (TLS 1.2+, AES-128+ at rest, 30-day PII deletion, PII-free logs, least-privilege access, Login with Amazon only). We build that complete, consistent file so the previous reason for refusal is gone.
Do you need access to our code, servers or Amazon account?
No. We are a marketplace-compliance firm, not a development agency. We prepare the documentation and the application Amazon requires, including the RDT and report-access narrative for this role, and your own IT lead implements the checklist on your infrastructure. We never touch your code, your servers or your Seller Central login.
Do I need an EU company to apply for the Tax Remittance role?
Not strictly, but a properly established company with a clean public presence and a real data-handling policy makes approval easier, and a compliant EU structure helps with VAT and data-protection expectations, directly relevant for a role about tax. We can set up a compliant Bulgarian company 100% remotely and align your structure, your VAT and your Amazon application so they support each other.
How long does Amazon take to approve the Tax Remittance role?
Amazon controls the final timing, so there is no guaranteed deadline. In our experience preparing restricted-role applications since 2018, a complete, compliant submission is typically reviewed within roughly 2 to 6 weeks. Public apps that also require the third-party Data Security Assessment add about a month for that step. The single biggest accelerator is a file that meets Amazon's security and compliance bar on the first attempt, which is exactly what we build.
Get the Tax Remittance role approved
Start the form and we will confirm your reports, your Orders operations and your RDT story, then build the complete compliance file Amazon scores. The standard restricted-role file is 650 €, delivered in 48 hours, obtained or refunded subject to our T&Cs. Building software for many sellers? Book a call for a tailored scope.
Content reviewed by Loïc Segui (COO & CTO), Fenchell's Marketplace Compliance Team · last updated 29 June 2026. We never promise approval: even when your file is prepared correctly, Amazon retains the right not to grant restricted access without justification. Technical names (roles, report types, operations) are reproduced from Amazon's official developer documentation. The figures shown on this page (accesses obtained, success rate) are based on real client cases and do not constitute a guarantee of outcome; results vary depending on your situation and Amazon's decision. Fenchell Capital OOD, Bulgarian firm based in Plovdiv (EIK 207945095).
Best Service. “Getting approved for access to the Amazon API was a real challenge for us. Fenchel and their team stepped in, audited our functionality, and helped us understand precisely what Amazon's software review team was looking for — which made all the difference.”
4.8/5