Avoid double-counting cloud network charges
On this page
This check is due for a source refresh. Confirm the current documentation before you rely on provider-specific details.
Reconcile one closed billing period by provider, billing function, and documented traffic path. Count each original charge line once, but keep credits, corrections, adjustments, taxes, and rounding lines separate. Matching byte totals are only a review signal because one path can have different billing boundaries.
Why this is worth a look
Google Cloud documents internet data transfer out, Cloud NAT, and load balancer charges for a regional internet NEG path, with different traffic scopes. Its pricing page also distinguishes Cloud CDN cache-fill transfer treatment. AWS product columns are dynamic and Azure cost details identify service, meter, resource, location, unit, and cost concepts. Use each provider's own export schema and do not merge fields across clouds.
Run this check
CHECKLISTUse this read-only procedure for one closed invoice period. It checks export coverage, preserves provider-specific schemas, maps traffic paths, and reconciles original lines with later corrections visible.
NETWORK CHARGE RECONCILIATION
EXECUTION SURFACE
Read-only review of AWS billing exports, Azure cost details, Google Cloud Billing exports, invoice or billing documents, architecture records, and resource mappings. Scope is one provider account or agreed account set per cloud, one closed invoice period, one currency, and a stated tax treatment. Record transfer units as reported by each provider. Do not combine provider schemas or units.
ASSUMPTIONS
[ ] The selected period is closed and the invoice or billing document is available.
[ ] Gross charge means the selected export's charge before credits; tax inclusion is recorded separately.
[ ] Billing exports and architecture records are read-only inputs.
1. CHECK EXPORT COVERAGE BEFORE TOTALING
[ ] Record each export's billing-account scope, first available date, selected invoice date or invoice-period value, and any interval when export was disabled.
[ ] Confirm the export covers the full invoice period. Google Cloud data can begin when export is enabled, and periods while export was disabled might be missing.
[ ] If coverage is incomplete, use the invoice or another complete source and label the export subtotal partial.
2. RETAIN PROVIDER-SPECIFIC FIELDS
[ ] AWS: retain the financial, usage, currency, invoice-period, adjustment or credit, account, and stable line-identity fields documented for the selected AWS Data Exports or CUR schema. Also retain product/dataTransfer, product/fromRegionCode, and product/usagetype when present. Product columns are dynamic and may be absent when the product was not used in the period.
[ ] Azure: retain the documented fields available in the selected cost-details format, including BillingAccountId, ConsumedService, Cost, Location, MeterCategory, MeterId, MeterName, MeterRegion, MeterSubCategory, ResourceId, ResourceLocationNormalized, Unit, UnitOfMeasure, and UsageDate. Do not assume every field exists for every account type.
[ ] Google Cloud: retain account ID, invoice date, service, SKU, project, location, usage, cost, credits, adjustments, currency, original usage date, and adjustment_info when present. Use detailed usage cost export only for resource-level mapping.
3. ASSIGN FUNCTION AND MAP THE PATH
[ ] Classify each line as transfer, processing, hourly infrastructure, CDN, tax, credit, correction, adjustment, or other.
[ ] Record source, destination, locations, direction, each documented gateway, proxy, inspection, CDN, or load-balancer hop, billing owner, units, and measurement boundary.
[ ] Compare bytes only when units, direction, tier, boundary, and period match. Google Cloud's regional internet NEG example has separate internet transfer, Cloud NAT, and load-balancer treatment on one path.
4. RECONCILE ORIGINALS AND LATER CHANGES
[ ] Group lines by the provider's invoice period or invoice date, not only by usage date. Keep the original usage date and adjustment or correction identifiers for traceability.
[ ] Count each original charge line once. Keep credits, taxes, corrections, adjustments, Google Cloud billing modifications, and Azure rounding-adjustment lines separate.
[ ] Tie complete-scope totals to the invoice or billing document, explain rounding differences, and leave unresolved lines visible with an owner.How to confirm it
- 01
Set the closed period and scope
Choose one provider account or agreed account set per cloud, one closed invoice period, one currency, and a stated tax treatment. Review only billing exports, invoice or billing documents, architecture records, and resource mappings. Record the time window and the provider-reported units.
- 02
Verify export coverage first
Record each export's billing-account scope, first available date, invoice date or invoice-period value, and any disabled interval. Google Cloud exports can start when enabled, and periods while an export was disabled might be missing. If coverage is incomplete, use the invoice or another complete source and label the export subtotal partial.
- 03
Keep schemas and financial lines separate
For AWS, retain the documented financial, usage, currency, invoice-period, adjustment or credit, account, and stable line-identity fields for the selected Data Exports or CUR schema, plus product/dataTransfer, product/fromRegionCode, and product/usagetype when present. For Azure, use available documented cost-detail fields such as Cost, ConsumedService, meter, resource, location, unit, and UsageDate. For Google Cloud, retain account ID, invoice date, service, SKU, project, location, usage, cost, credits, adjustments, and currency, adding detailed export data only for resource-level mapping.
- 04
Map functions to the traffic path
Classify each line as transfer, processing, hourly infrastructure, CDN, tax, credit, correction, adjustment, or other. Record source, destination, direction, locations, units, measurement boundary, and every documented gateway, proxy, inspection, CDN, or load-balancer hop. The Google Cloud regional internet NEG example shows separate internet transfer, Cloud NAT, and load-balancer treatment on one path.
- 05
Reconcile and investigate exceptions
Group lines by the provider's invoice period or invoice date, not only usage date, while preserving original usage dates and adjustment identifiers. Count each original line once. Keep credits, taxes, corrections, adjustments, Google Cloud billing modifications, and Azure rounding-adjustment lines separate, then tie complete-scope totals to the invoice and leave unresolved lines visible.
Before making changes
Assume one closed invoice period, a defined account scope per cloud, one currency, and an explicit tax treatment. Do not combine provider fields or transfer units. AWS financial and line-identity fields vary by the selected export schema, and AWS product columns are dynamic. Google Cloud standard export lacks resource-level cost data and can have coverage gaps. Azure Location may be blank or unassigned for purchases and Marketplace usage. Later corrections can appear as separate Google Cloud lines on a later invoice.