A practical readiness check for AWS Partners moving to the Bill Transfer and Bill Source model.
TL;DR
AWS Billing Transfer changes who pays the bill, what each account can see, and how cost data is exported. Treat the transition as a data continuity project, not an account-setting change. Before cutover, preserve historical data, map billing views, rebuild CUR exports, validate access across both account roles, and test every FinOps workflow that depends on the data.
AWS Billing Transfer changes more than billing ownership
AWS Billing Transfer allows one management account to manage and pay the consolidated bill of another AWS Organization.
For AWS Partners, the Bill Transfer account typically serves as the Partner Management Account, or PMA. It receives bills transferred by customer organizations operating as Bill Source accounts.
That changes the financial relationship between the partner and the customer. It also changes how cost data is generated, accessed, exported, and presented.
The Bill Transfer account gains access to two distinct perspectives:
My View shows the actual billing data for which the partner is financially responsible.
The Showback/Chargeback View shows the customer-facing cost data configured through AWS Billing Conductor, including partner-defined pricing.
These views serve different financial purposes. They also generate different cost exports.
This is why Billing Transfer should not be treated as a routine account migration. It is a data continuity project with consequences for reporting, forecasting, recommendations, customer billing, and operational workflows.
The five-part Billing Transfer readiness check
1. Preserve historical data before cutover
AWS states that after Billing Transfer becomes active, historical cost data becomes unavailable in Cost Explorer, AWS Budgets, and AWS Cost Anomaly Detection. Existing CUR files also become unavailable through the new billing relationship.
Before approving the transition, export and preserve the historical data required for customer reporting, trend analysis, forecasting, reconciliation, and audits.
Do not wait until the first post-transfer review to discover that the baseline is no longer accessible.
2. Rebuild the CUR strategy around Billing Views
Existing CUR configurations do not simply continue under the new structure. AWS notes that they become unhealthy after the transfer and must be reconfigured.
Each Billing View maintains its own independent exports.
The partner-facing My View export contains the actual AWS cost data for which the Bill Transfer account is responsible. The Showback/Chargeback View export contains the customer-facing data configured through Billing Conductor.
The two exports may require different names, S3 paths, and operational handling. Creating a CUR without first confirming the active Billing View can produce the wrong financial perspective while still generating a technically valid file.
Before onboarding, define which view supports each reporting and billing workflow.
3. Validate access across both account roles
Billing Transfer onboarding can require coordinated access across the Bill Transfer account and the Bill Source account.
That includes identifying the correct management accounts, configuring IAM roles and policies in the appropriate environments, providing the required account IDs and role ARNs, and confirming access to the relevant CUR location.
For partner-side onboarding, S3 bucket uniqueness also matters. Each Bill Source account under the same PMA must use the correct dedicated invoice bucket configuration.
A setup can look complete in one account while still failing because the corresponding role, policy, bucket, or identifier is missing in the other.
4. Separate partner cost from customer-facing cost
Billing Transfer creates a deliberate separation between the partner’s actual AWS cost and the rates presented to the customer.
That distinction is operationally valuable, but it must be tested.
AWS notes that pro forma data may not automatically include every pricing component, including certain support charges, credits, and Free Tier elements. Partners should verify that the Showback/Chargeback View reflects the intended commercial model before using it for customer billing or financial reporting.
A technically successful transfer does not automatically mean the customer-facing numbers are commercially complete.
5. Test the workflows that depend on the data
CUR delivery is only the beginning of the validation process.
After the transfer, test the workflows that depend on the new data structure:
- Cost and usage reporting
- Customer showback and chargeback
- Budgets and forecasts
- Anomaly monitoring
- Commitment and optimization analysis
- Recommendations
- Customer billing and margin reporting
- Scheduled reports and dashboards
The important question is not only whether data arrived.
It is whether the partner can still explain the bill, operate the customer workflow, and take action from the result.
Where Umbrella fits
Umbrella is the first FinOps platform to natively support AWS Billing Transfer onboarding through a flow designed for the Bill Transfer and Bill Source model.
The onboarding experience adapts to the selected account role and helps partners work through the requirements of the new structure, including:
Role-specific onboarding paths
The correct CUR Billing View selection
Separate Bill Transfer and Bill Source account details
IAM configuration across both account roles
S3 bucket uniqueness validation
Access validation before data processing
Umbrella recommends onboarding through the Bill Transfer account, or PMA, to preserve the existing cost visibility, recommendations, and billing workflows used by the partner and its customers.
This continuity applies to the operational experience within Umbrella. It does not remove AWS’s requirement to preserve historical data before the transition or recreate the required exports after Billing Transfer becomes active.
Recommendations also depend on connecting the relevant linked accounts, so this should be included in the post-transfer validation plan.
When you are ready to configure the integration, follow the onboarding guide that matches the account role:
Partners onboarding through the PMA should follow the Bill Transfer Account onboarding guide.
Teams onboarding the customer’s management account should follow the Bill Source Account onboarding guide.
A practical cutover checklist
| Before activation | After activation |
|---|---|
| Confirm the Bill Transfer and Bill Source account roles | Recreate CUR exports under the correct Billing Views |
| Preserve historical cost and usage data | Validate data delivery and processing status |
| Record the effective date and ownership model | Compare partner cost with customer-facing cost |
| Map My View and Showback/Chargeback workflows | Test dashboards, reports, recommendations, and billing |
| Inventory existing CURs, buckets, roles, and policies | Document any remaining AWS data limitations |
A Billing Transfer migration is not complete when the invitation is accepted.
It is complete when the partner can reconcile the first post-transfer bill, explain the customer-facing cost, and operate the FinOps workflows that follow.
For a step-by-step walkthrough of the account roles, CUR configuration, IAM setup, and validation process, see Umbrella’s AWS Billing Transfer onboarding guide.
Planning an AWS Billing Transfer cutover and want to pressure-test the workflow? Let’s talk FinOps.
*Updated July 2026 to reflect AWS Billing Transfer data-history, Billing View, and CUR requirements.