Summary

Starting April 15, 2026, public.transactions will be available and will replace the legacy public.transaction_standard_orders and public.transaction_invoiced tables; legacy support ends June 15, 2026. The new table is a single daily-updated (30-day lookback) ledger-style view (one row per transaction line item / charge type) with stable Finance API–backed identifiers (e.g., transaction_id, shipment_id, refund_id, financial_event_group_id, settlement_id) and consistent English field names across marketplaces. Note: the Finance API limits history to ~2 years (older data won’t be available in public.transactions), and some fields like State/Zip are not present.

Key compatibility changes include renamed columns (e.g., type → transaction_type, product-name description → item_description, quantity → quantity_shipped, marketplace → marketplace_name, fulfillment → fulfillment_network, transaction_release_date → maturity_date) and updated transaction_type values (e.g., legacy Order → Shipment). Amazon also sends date_time in PST and maturity_date in UTC. For deferred transactions, Amazon emits both the initial deferred row and the released row; to avoid double-counting, filter to deferred_transaction_id IS NULL (or additionally require released statuses when you only want paid transactions).

Full Details

We recommend beginning your migration as soon as public.transactions is available. If you have questions about the timeline or need more runway, reach out to your account contact.

What Is public.transactions

public.transactions is a single view that replaces both public.transaction_standard_orders and public.transaction_invoiced. It is updated daily with a 30-day lookback.

Rather than the wide, column-per-type format you may be used to, this table is structured as a ledger — one row per transaction line item and charge type. This makes it easier to work with programmatically and eliminates the need to maintain custom column mappings per marketplace.

What's Different

⚠️ Historical data limit public.transactionscovers up to 2 years of history — this is a limitation of Amazon's Finance API. Data older than 2 years is not available in the new table. public.transaction_standard_orders & public.transaction_invoiced will remain in your database for historical reference.

Column Name Changes

Most columns carry over, but several have been renamed or behave differently:

transaction_type Value Changes

The type field from the legacy reports is now transaction_type, and the values have been renamed:

Note: What the legacy report called Order is now Shipment.

Timezone Notes

• date_time: Amazon sends this in PST
• maturity_date: Amazon sends this in UTC

breakdown_type Reference

The breakdown_type column replaces the individual revenue and expense columns from the legacy reports. Instead of a column called fba_fees, you now get a row where breakdown_type = 'FBAPerUnitFulfillmentFee'.

Below are the common mappings. Amazon defines the full list of possible values — this is a reference, not a complete enumeration.

Revenue

Discounts & Promotions

Amazon Fees

Tax

Reimbursements & Adjustments

FBA fees are now broken out. The legacy report lumped most FBA charges into a single fba_fees column. The Finance API separates them — Storage, Long-Term Storage, Removal, Disposal, and Inbound Freight each get their own row. If your reporting previously relied on fba_fees as a single number, you’ll want to decide which subtypes belong in that bucket going forward.

A note on P&L mapping: How you group breakdown_type values into your own P&L categories is specific to your reporting needs. We provide the values as Amazon defines them — your team owns the logic that maps them to your internal buckets.

Deferred Transactions

Amazon defers payment on certain transaction types — most commonly B2B invoiced orders (paid 30–45 days after the order) and delivery-date based holds (7 days). The Finance API handles these natively, but it helps to understand how the data is structured.

When a transaction is deferred, Amazon sends it twice: once when the order is placed (status: DEFERRED) and again when payment is released (status: Released). To avoid double-counting, you'll need to filter based on your use case.

Use Case 1: I want all sales and costs — I don't need to track deferred status

Filter to rows where deferred_transaction_id IS NULL. This gives you exactly one row per transaction regardless of whether it was deferred or not. Deferred orders will appear at their original order date.

WHERE deferred_transaction_id IS NULL

Use Case 2: I only want transactions that have actually been paid

Filter to rows where payment has been released AND exclude the re-sent duplicate row:

WHERE transaction_status IN ('Released', 'DEFERRED_RELEASED')
  AND deferred_transaction_id IS NULL

This excludes transactions still pending payment (DEFERRED) and avoids double-counting when a deferred transaction is released.

pl_ledger_table

pl_ledger_table users: This migration does not apply to you at this time. We'll be launching a replacement for pl_ledger_table that takes full advantage of the Finance API's improved data structure — including enhanced currency handling. Expect an announcement towards the end of Q2 2026.