### Summary
We request that IBM Turbonomic officially support the ingestion of Cost and Usage Report (CUR) data that has been transformed or custom-generated by the customer, and that IBM publish the complete specifications (required columns, data types, field lengths/formats, and manifest file schema) needed to produce such data.
### Background and problem
In our environment, the AWS management account is owned and operated by a separate infrastructure team. The CUR is delivered to us only after it has been split per member account (per company/organization unit) and replicated into our S3 bucket. Only the `data/` (Parquet) files are replicated; the AWS-generated `metadata/` (Manifest) is not included.
Because of this, we attempted to convert the delivered Parquet into a Legacy CUR (gzip-CSV + manifest) and generate the manifest ourselves. Despite making the CSV content fully valid (cleaning null values, flattening CUR 2.0 map columns such as product/resource_tags, fixing manifest column-name prefixes, removing Content-Encoding to avoid double decompression, etc.), Turbonomic continued to fail with:
`Critical: Failed to process billing report files.`
Through this investigation we confirmed, based on IBM documentation, that:
- Custom CUR configurations (including customer-generated manifests) are not supported ("Custom CUR configurations are not supported").
- Only data exports associated with a management account are supported; member/standalone account data exports are not supported.
### Why this is a problem for us
Our organization cannot share the management-account-level (organization-wide) CUR directly, because it contains cost data of other companies/departments and crosses our internal data-segregation boundary. Therefore we can only receive member-account-level, split data. This means:
- We cannot use the AWS-native, management-account-level export that Turbonomic requires.
- We also cannot make Turbonomic accept our transformed / self-generated data.
As a result, there is currently **no viable path** for us to ingest cost data into Turbonomic, even though the underlying billing data itself is available to us.
### What we are requesting
1. **Officially support transformed / custom-generated CUR data** as a valid input for the AWS Billing target (i.e., allow customer-produced CSV + manifest, or provide a supported ingestion path that does not require the AWS-native, management-account-level export).
2. **Publish the complete input specification** required to produce a valid, ingestible dataset, including:
- The exact list of required and optional columns.
- The data type of each column (String / Double, etc.).
- Field length / format constraints (e.g., date format, account ID zero-padding, decimal/scientific-notation handling).
- The full manifest (Manifest.json) schema, including required keys, the correct `category` / `name` conventions, compression/contentType expectations, and the expected S3 path/layout.
- Clear validation rules or error references so that ingestion failures can be diagnosed without repeated trial-and-error.
### Business impact
We are scheduled to conduct an effectiveness evaluation in December 2026 to decide whether to continue using Turbonomic. In the current state—where only exports produced directly by AWS (management-account-level, AWS-native manifest) are supported—we are structurally unable to ingest our cost data, and therefore **cannot perform the effectiveness evaluation at all**. If this cannot be resolved before the evaluation, it is highly likely that we will not be able to justify continuing the license.
Publishing the specification and supporting transformed data would allow customers in environments with data-segregation constraints (where the management-account CUR cannot be shared as-is) to still leverage Turbonomic's cost optimization capabilities.
