Migration assurance
Finances listTransactions reconciliation validator
listTransactions replaces the v0 financial-event lists with a single transaction model that carries recursive breakdowns. This validator accepts a request manifest plus one or more page samples, then checks window safety, pagination progression, duplicate IDs and recursive breakdown totals against optional expected totals.
- Input: Request manifest, one or more listTransactions page samples, optional expected totals
- Output: Window, safety, token, duplicate and reconciliation issues
- Method: Deterministic decimal reconciliation. No code executed.
What it checks
postedAfter..postedBefore windows over the 180-day limit, which can return an empty response; two-minute safety windows for recent data; page-chain completeness; empty pages while nextToken exists; repeated tokens; preservation of original request arguments; duplicate transaction IDs; and recursive breakdown[] totals rolled up per transaction.
Why it matters
The validator checks whether the supplied pages and optional expected totals reconcile under deterministic reference rules. It does not execute or prove your production roll-up implementation.
Supported input formats and limits
| Input | Format | Limit |
|---|---|---|
| Request manifest | JSON with postedAfter, postedBefore, requestedAt and optional pages[] | Maximum 1 MB |
| Page samples | Actual listTransactions response or {pages:[{payload:{transactions,nextToken}}]} | Maximum 10 MB for transactions/pages and 1 MB for the request manifest |
| Transaction cap | payload.transactions[] across supplied pages | Maximum 50,000 transactions |
| Breakdown depth | Recursive breakdowns[] tree with breakdownAmount Currency objects | Maximum depth 25 |
| Expected totals | Optional manifest totals for reconciliation | Optional |
Redaction behavior
The validator reports transaction IDs, issue codes and aggregate amounts needed for reconciliation. It never calls Amazon and does not export raw secret values.
Exact checks
- postedAfter..postedBefore ranges over 180 days, which can return an empty response.
- Samples over 10 MB, manifests over 1 MB, transaction counts over 50,000 or breakdown depth over 25 are rejected or failed.
- postedAfter, postedBefore and requestedAt must be ISO 8601 datetimes such as 2026-01-01T00:00:00Z; date-only and space-separated datetimes are rejected.
- Validate both postedAfter and postedBefore against requestedAt.
- Both timestamps must be more than two minutes before the request.
- postedAfter too close to request time is reported as POSTED_AFTER_TOO_RECENT.
- postedBefore too close to request time is reported as POSTED_BEFORE_TOO_RECENT.
- postedBefore must be later than postedAfter.
- Incomplete page chains, empty pages with nextToken and repeated tokens.
- Token pages that fail to preserve original request arguments.
- Duplicate transaction IDs and recursive breakdown total mismatches.
- totalAmount and breakdownAmount must use the Amazon Currency object shape with currencyCode and currencyAmount.
- Multi-page wrapper schema is {"pages":[{"payload":{"transactions":[],"nextToken":null}}]}; each payload is an actual listTransactions response body.
Sample input
transactions: {
"pages": [
{
"payload": {
"transactions": [
{
"transactionId": "t1",
"transactionStatus": "RELEASED",
"totalAmount": {"currencyCode": "USD", "currencyAmount": 1.00},
"breakdowns": []
}
],
"nextToken": null
}
}
]
}
manifest: {"postedAfter":"2026-01-01T00:00:00Z","postedBefore":"2026-01-31T12:00:00Z","requestedAt":"2026-01-31T12:05:00Z"}Sample output
{
"status": "PASS",
"transactionsTotal": 1,
"paginationComplete": true,
"issues": []
}PASS, PARTIAL, FAILED and NOT_VERIFIED logic
| Status | Meaning |
|---|---|
| PASS | The supplied pages reconcile and pagination/window checks pass. |
| PARTIAL | Medium-severity reconciliation or coverage issues require review. |
| FAILED | High-severity window, pagination, duplicate or total issues are present. |
| NOT_VERIFIED | No transactions or insufficient sample data were supplied. |
Known limitations
- Sample pages do not prove 48-hour production completeness.
- Runtime-generated request windows can require manual verification.
- Expected accounting totals outside the supplied manifest are not inferred.
Pricing entitlement
Single unlocks the Finances validator when Finances is the purchased module. Bundle and Agency include all three validators.
Frequently asked questions
What is the window limit?
If postedAfter and postedBefore are more than 180 days apart, Amazon returns an empty response. Split larger ranges into windows of 180 days or less.
Official sources
Last reviewed: 2026-07-02.
Open the interactive scanner: /app#/validators