Invoke-CostExportV2IngestData

[francesco1119]

Are you submitting your tool or someone else's?

I'm submitting a suggestion for someone else's tool (please specify below).

Tool ownership responsibilities (only applicable to tool owners)

• I acknowledge the responsibilities of a technical lead and agree to serve in this role for the proposed tool upon its approval.

Tool name

Invoke-CostExportV2IngestData

Description

I've been using the module Invoke-CostExportV2IngestData developed by Darshit Saha.

The module has a cascade menu that allows the user to export directly to the msexports Container in the Storage Account dedicated to the FinOps Toolkit.

Use case

It's useful to backfill the FOCUS months

Services used

PowerShell

Dependencies

No response

[RolandKrummenacher]

Hello — thank you for proposing the addition of Invoke-CostExportV2IngestData to the FinOps Toolkit. I’d like to better understand how this module compares to the existing supported backfill/export workflow. Specifically:

• In what scenarios do you see Invoke-CostExportV2IngestData giving a clear advantage over the standard backfill approach via Start-FinOpsCostExport?
• Does it improve reliability, performance, or reduce manual steps compared to the existing export/backfill + ingestion pipeline?
• Are there limitations or edge-cases in the standard method that this module avoids (e.g. throttling, data format issues, historical export range, ease of integration into pipelines)?
• From a maintenance and support perspective — what would be the benefits/risks if this module becomes part of the core Toolkit (e.g. compatibility, updates, official support)?

Thank you for clarifying.

[francesco1119]

You don't have to hardcode the URL, ex:

-Scope '/providers/Microsoft.Billing/billingAccounts/1234'

Invoke-CostExportV2IngestData list all EA and MCA.

[flanakin]

I see it works more like an interactive CLI than a typical PowerShell command. We could totally bring something like this in. We would need Darshit to do the contribution due to copyright issues. They would need to contribute the code into the repo themselves. But assuming they do that, we could totally bring it in.

I'm curious how you'd like to see it brought in. Do you see it being independent exactly as it is today or should we bake this interactive selection into the existing commands? I'm open to either. We'd just want to add an option to opt into the interactivity or maybe just do it when the data is missing. Easy things to figure out.