Invoice Issuer concerns

flanakin commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 6 months ago

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

jpradocueva commented 6 months ago

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.

shawnalpay commented 3 weeks ago

@flanakin Please provide context as to whether we should carry this issue forward. @ijurica To refresh on this issue and provide any further context / content as necessary.

jpradocueva commented 3 weeks ago

TF-2 call on Oct 15:

Topic: #299 Invoice issuer concerns Discussion Summary: The issue centered on whether the FOCUS Spec adequately addresses the complexity of identifying the invoice issuer in various billing scenarios (e.g., resellers). It was agreed that the spec is fine, but some supporting content might be needed to clarify specific cases. Resolution: The issue was flagged for further review, with one team member tasked with documenting the discussion to include in supporting content.

jpradocueva commented 3 weeks ago

Summary TF-2 Call on Oct 16:

#299 Invoice Issuer Concerns Primary Issue: Unclear definition and handling of invoice issuer, with some legal implications discussed. Core Problem: Lack of clarity around what the invoice issuer field should reflect. Divergent Views: Some felt the field's requirements were too ambiguous, while others mentioned potential legal concerns. Final Agreement: Further clarification is needed; this issue will remain under review. Action Items: [TF-2-#299] Michael, @flanakin is assigned to follow up with the member who initially raised the issue and clarify concerns.

jpradocueva commented 2 weeks ago

Summary Members' call on Oct 17:

#299 Invoice Issuer Concerns Primary Issue: Defining the role and attributes of the "Invoice Issuer" in the specification, and addressing concerns around its current interpretation. Core Problem: The current definition of "Invoice Issuer" may be too ambiguous, leading to inconsistent interpretations among practitioners. A clear definition is needed to prevent confusion, especially when different cloud providers have unique billing practices. Divergent Views: Some members believed the current definition was adequate but could benefit from additional context. Others, particularly those dealing with multi-cloud environments, found the definition too vague and potentially misleading. Final Agreement: The group agreed to revisit the definition of "Invoice Issuer," with Michael and Irena tasked to follow up with key stakeholders for further clarification. Action Items:

[ ] [Members-#299] Michael @flanakin : Follow up with AWS and GCP representatives to gather feedback on the current definition and how it is interpreted.
[ ] [Members-#299] Irena, @ijurica : Review current supporting content for Invoice Issuer and suggest any additional clarifications.

arrarama commented 2 weeks ago

@flanakin and @ijurica - Please include me in this conversation. OCI has a reseller model where resellers are essentially selling a private label version of OCI including features such as FOCUS reports and the invoice issuer will be important to get right.

shawnalpay commented 6 days ago

@flanakin Please follow up with Zach, Tim, and Arun on this topic and feel free to include me.

jpradocueva commented 5 days ago

Comments from Members' call on Oct 31:

Analysis: Involves clarifying the definition and use of invoice issuers in cases of multi-level invoicing. Agreements: Shawn will follow up with Zach and Tim to gather additional feedback from practitioners before deciding on next steps.

FinOps-Open-Cost-and-Usage-Spec / FOCUS_Spec