Invoice Issuer concerns

[flanakin]

Type

Dimension: InvoiceIssuerName An Invoice Issuer is an entity responsible for invoicing for the resources or services consumed. It is commonly used for cost analysis and reporting scenarios.

Description

There are scenarios where the InvoiceIssuerName may not be the organization that generates the invoice for the end customer because the provider doesn't know about the multiple layers of intermediaries (e.g., distributors, providers, resellers) between the originating provider and the customer. The originating provider will generate the data that the end customer may see, but the end customer may not even know about the upstream organization that was the direct partner of the originating provider. For example, I may get cloud services from and am invoiced by Breezy Bytes LLC, but it's actually Azure under the covers. I don't know who Breezy Bytes is working with. I just know it's Azure and I get my cost data from Microsoft. Let's assume the following set of relationships:

Me > Breezy Bytes LLC > Cloudy Clusters Inc > Sunny Systems Gmbh > Microsoft

As a customer, I only know Breezy Bytes and Microsoft may only know about Sunny Systems. Neither of us may know about the extra intermediary. Legally, I'm not sure if Microsoft can even disclose upstream intermediaries. (I haven't checked yet.)

Also, during internal discussions, several people questioned what "invoice issuer" meant and felt it wasn't very clear. They were asking if this is a standard term across the industry and, if not, if there is a standard term.

Definition of done

• [x] Rationalize vendor-neutral, cross-cloud naming
• [x] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc.

Want this column in FOCUS 1.0 GA?

Give it a 👍 below ↴

If you can discuss and help finalize the change, add yourself as an assignee ↗

Comments are welcome and encouraged!

[mike-finopsorg]

As far as I understood the InvoiceIssuer will always match who sent you the invoice, so it changes as you go back up your stack

Me > Breezy Bytes LLC > Cloudy Clusters Inc > Sunny Systems Gmbh > Microsoft

Microsoft will send an invoice to Sunny Systems Gmbh with the InvoiceIssuer as Microsoft Sunny Systems Gmbh will send an invoice to Cloudy Clusters Inc with InvoiceIssuer as Sunny Systems Gmbh Cloudy Clusters Inc will send an invoice to Breezy Bytes LLC with InvoiceIssuer as Cloudy Clusters Inc And then finally you receive an invoice with Breezy Bytes LLC as the InvoiceIssuer

The Provider/Publisher will allow you to see its services provided by Microsoft.

I see this as Item number 2 on https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/supporting_content/appendix/origination_of_cost_data.md

Unless I am not following your example correctly.

[udam-f2]

In these scenarios, the intermediaries can't just provide the raw billing data they incurred and be FOCUS compatible. As Mike said, if Breezy Bytes LLC is providing the invoice to you, they should have that on the invoice issuer. It won't be Microsoft's responsibility to show the Invoice Issuer as Breezy Bytes LLC or any other entity above them unless they have some partnership/agreement to produce the actual billing data on behalf of the intermediary.

[flanakin]

If the intermediaries are providing data, then that's fine. But what happens when the provider sends the data to the end user? The provider won't always know who sent the invoice to the end customer. Therefore, it's not actually possible to guarantee it's being set correctly from their perspective. This effectively means the definition of the column cannot be upheld, if I'm understanding correctly.

@jpradocueva I'm going to remove the milestone and set this as a breaking change. I think we need an explicit discussion about this one given the legal implications. Hopefully I'm blowing it out of proportion, but I do think it's worth explicitly discussing.

[mike-finopsorg]

I don't see why the provider wouldn't just assume they are the invoice issuer in this scenario, as you say you can't know there is an MSP at time of FOCUS data generation. The CSP provides the billing data from the perspective of their invoice to customer.

If an MSP is taking the CSP invoice and making a new invoice for their customers, then they (MSP) either (ideally) cut their own copy of the FOCUS data for their customer—updating the invoice issuer—or allow their customer to see their (MSP's) copy of the CSP provided FOCUS billing data (showing Invoice issuer as the CSP).

Put basically, everyone generates their FOCUS data from the perspective of their own invoicing process. If an end customer accesses the dataset from the original source (CSP) when they have an intermediary invoice issuer they are seeing the data from the perspective of the CSP and would just need to be made aware of this—by their intermediary.

[udam-f2]

Put basically, everyone generates their FOCUS data from the perspective of their own invoicing process. If an end customer accesses the dataset from the original source (CSP) when they have an intermediary invoice issuer they are seeing the data from the perspective of the CSP and would just need to be made aware of this—by their intermediary.

100% agree

[mike-finopsorg]

Suggestion on clarifying language here:

Note: This field is populated from the perspective of the billing data generator. If an intermediate provider is invoicing a customer, but providing the data generated by the underlying cloud provider the Invoice Issuer will reflect the cloud provider as the invoice issuer.

Can we get some feedback and revisions here to come to a good set of words to help clarify the column for the user.

cc: @arrarama / @flanakin / @rupagcp

[mike-finopsorg]

Further conversation in the weekly meeting identified a possible future column to help with this is a DataGenerator column to ensure the practitioner using the data is able to identify who created the dataset no matter where they acquired the data from. I have opened #357 a related issue for this.

[jpradocueva]

The Maintainers agreed to present this issue to the Task Forces 1 & 2

[jpradocueva]

The group agreed to move the issue to v1.1 @ijurica please comment on this issue based on the discussion on FT-1, April 16.