Repository: FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec
Pull request #830: WI #616: Initial Example Section - cleaned up data and spec content
Author: login: UdamDewaraja
Labels: name: spec revision
description: Revise existing definition to be clearer or more accurate
Created: 2025-03-07T06:45:35Z | Merged: 2025-03-28T02:11:26Z

Updating the structure of the SaaS examples, Adding spend requirements section, build and markup fixes

This is a subset of the work done in https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/pull/688. There's too many things to clean up and push at once in that PR - so breaking it down to a smaller PR. 

@rileyjenk has agreed to this new formatting.


Diff:
diff --git a/specification/Makefile b/specification/Makefile
index c74021fe34..e9b25b2fce 100644
--- a/specification/Makefile
+++ b/specification/Makefile
@@ -32,8 +32,8 @@ endif
 	./validate_includes.py metadata/schema
 	./validate_includes.py metadata/schema/column_definition
 	./validate_includes.py appendix
-	./validate_includes.py appendix/examples
-	./validate_includes.py appendix/examples/metadata_examples
+	./validate_includes.py appendix/metadata_examples
+	./validate_includes.py appendix/saas_examples
 	PYTHONPATH=../vendored/ $(MARKDOWNPP) spec.mdpp -o $@
 	$(PYMARKDOWNLNT) --config markdownlnt.cfg scan $(SPEC_SOURCE_MDFILES)
 	$(PYMARKDOWNLNT) --config markdownlnt.cfg scan $@
diff --git a/specification/appendix/appendix.mdpp b/specification/appendix/appendix.mdpp
index 06827fe9a1..414b7a0d21 100644
--- a/specification/appendix/appendix.mdpp
+++ b/specification/appendix/appendix.mdpp
@@ -6,3 +6,5 @@
 !INCLUDE "examples/examples.mdpp",1
 !INCLUDE "grouping_constructs_for_resources_and_or_services.md",1
 !INCLUDE "origination_of_cost_data.md",1
+!INCLUDE "metadata_examples/metadata_examples.mdpp",1
+!INCLUDE "saas_examples/saas_examples.mdpp",1
diff --git a/specification/appendix/examples/metadata_examples/adding_new_columns_example.md b/specification/appendix/metadata_examples/adding_new_columns_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/adding_new_columns_example.md
rename to specification/appendix/metadata_examples/adding_new_columns_example.md
diff --git a/specification/appendix/examples/metadata_examples/changing_column_metadata_example.md b/specification/appendix/metadata_examples/changing_column_metadata_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/changing_column_metadata_example.md
rename to specification/appendix/metadata_examples/changing_column_metadata_example.md
diff --git a/specification/appendix/examples/metadata_examples/correcting_schema_errors_example.md b/specification/appendix/metadata_examples/correcting_schema_errors_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/correcting_schema_errors_example.md
rename to specification/appendix/metadata_examples/correcting_schema_errors_example.md
diff --git a/specification/appendix/examples/metadata_examples/data_generator_example.md b/specification/appendix/metadata_examples/data_generator_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/data_generator_example.md
rename to specification/appendix/metadata_examples/data_generator_example.md
diff --git a/specification/appendix/examples/metadata_examples/focus_version_changed_example.md b/specification/appendix/metadata_examples/focus_version_changed_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/focus_version_changed_example.md
rename to specification/appendix/metadata_examples/focus_version_changed_example.md
diff --git a/specification/appendix/examples/metadata_examples/focus_version_changed_with_provider_version_used_example.md b/specification/appendix/metadata_examples/focus_version_changed_with_provider_version_used_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/focus_version_changed_with_provider_version_used_example.md
rename to specification/appendix/metadata_examples/focus_version_changed_with_provider_version_used_example.md
diff --git a/specification/appendix/examples/metadata_examples/metadata_examples.mdpp b/specification/appendix/metadata_examples/metadata_examples.mdpp
similarity index 100%
rename from specification/appendix/examples/metadata_examples/metadata_examples.mdpp
rename to specification/appendix/metadata_examples/metadata_examples.mdpp
diff --git a/specification/appendix/examples/metadata_examples/provider_version_changed_example.md b/specification/appendix/metadata_examples/provider_version_changed_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/provider_version_changed_example.md
rename to specification/appendix/metadata_examples/provider_version_changed_example.md
diff --git a/specification/appendix/examples/metadata_examples/removing_columns_example.md b/specification/appendix/metadata_examples/removing_columns_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/removing_columns_example.md
rename to specification/appendix/metadata_examples/removing_columns_example.md
diff --git a/specification/appendix/examples/metadata_examples/schema_metadata_example.md b/specification/appendix/metadata_examples/schema_metadata_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/schema_metadata_example.md
rename to specification/appendix/metadata_examples/schema_metadata_example.md
diff --git a/specification/appendix/examples/metadata_examples/schema_metadata_reference_example.md b/specification/appendix/metadata_examples/schema_metadata_reference_example.md
similarity index 100%
rename from specification/appendix/examples/metadata_examples/schema_metadata_reference_example.md
rename to specification/appendix/metadata_examples/schema_metadata_reference_example.md
diff --git a/specification/appendix/saas_examples/saas_examples.mdpp b/specification/appendix/saas_examples/saas_examples.mdpp
new file mode 100644
index 0000000000..a907c086a3
--- /dev/null
+++ b/specification/appendix/saas_examples/saas_examples.mdpp
@@ -0,0 +1,6 @@
+# SaaS Examples
+
+The following section contains examples with how SaaS providers may implement the FOCUS specification. SaaS provider implementations will vary on the level of the detail available in their data, contract terms, purchasing options, and other factors.
+
+!INCLUDE "simple_agreements.md",1
+!INCLUDE "spend_agreements.md",1
\ No newline at end of file
diff --git a/specification/appendix/saas_examples/simple_agreements.md b/specification/appendix/saas_examples/simple_agreements.md
new file mode 100644
index 0000000000..3e1d6a7fbd
--- /dev/null
+++ b/specification/appendix/saas_examples/simple_agreements.md
@@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
+  
+## Scenario A2: Invoice Up-front for a Quantity of a Service
+
+ACME Corp offers its customer the ability to purchase a fixed quantity of licenses for their service. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+On April 1st, 2025, ACME executes a contract and invoices AwesomeCorp &dollar;50,000 (Billed Cost) for a Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
+
+**Example FOCUS dataset:** [Invoice up-front entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A11)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 to April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement is charged in the first invoice. Billed Cost and Effective Cost are both realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge provided includes a ListUnitPrice for the licenses and a Pricing Quantity.
+
+## Scenario A3: Additional Purchase Records Provided in the SaaS Provider's FOCUS Data
+
+On June 1st 2025 ACME provides the following records due to AwesomeCorp's &dollar;1,000 mid-contract purchase of an additional 10 licenses for the same Charge Period (April 1st 2025 to April 1st 2026).
+
+**Example FOCUS dataset:** [Additional license purchase entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A14)
+
+Note the following additional details in the dataset:
+
+* The Charge Period is still April 1st 2025 to April 1st 2026. The Billing Period is now the month of June 2025 (when the additional licenses were ordered) and therefore will appear in the June 2025 invoice.
+
+## Scenario B: Billed in Arrears for a Quantity of a Service
+
+Similar to Scenario A above, ACME Corp offers its customer the ability to purchase their service with a fixed quantity of licenses. However, in Scenario B, ACME issues the invoice at the end of the usage period.
+
+On April 1st, 2026, ACME invoices AwesomeCorp &dollar;50,000 (Billed Cost) for the Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
+
+**Example FOCUS dataset:** [Billed in arrears entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A17)
+
+Note the following additional details in the dataset:
+
+* The Charge Period is April 1st 2025 to April 1st 2026. The Billing Period is now the month of March 2026 (since this charge is invoiced as of the last month of the Charge Period).
+
+## Scenario C: Simple SaaS Agreement with Monthly Billing
+
+Like Scenario A2 above, ACME Corp offers its customers the ability to purchase their service with a fixed quantity of licenses. However, in Scenario C, ACME issues invoices at the end of each month (usage period).
+For this scenario, contract terms additionally include the following terms:
+
+* ACME charges users monthly for the licenses that were consumed in that Billing Period
+* The licenses are charged at &dollar;20 per license per month
+
+AwesomeCorp's consumption looks like this:
+
+* In April 2025, AwesomeCorp uses 505 licenses
+* In May 2025, AwesomeCorp uses 650 licenses
+* In June 2025, AwesomeCorp uses 635 licenses
+
+**Example FOCUS dataset:** [Billed in arrears monthly entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A20)
+
+Note the following additional details in the dataset:
+
+* The Charge Period and Billing Period are April 1st, 2025, to May 1st, 2025, for the first month. Subsequent months increment the Charge Period and Billing Period by one month to match the month the charges are incurred.
+* Billed Cost and Effective Cost are the same value since there is no up-front payment to amortize
diff --git a/specification/appendix/saas_examples/spend_agreements.md b/specification/appendix/saas_examples/spend_agreements.md
new file mode 100644
index 0000000000..e8b9e49255
--- /dev/null
+++ b/specification/appendix/saas_examples/spend_agreements.md
@@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme Co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorp's consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=1987749478#gid=1987749478&range=A15)
+
+Note the following details in the dataset:
+
+* A single charge representing the total unused amount from the 12-month agreement is charged during the final month of the 12-month term
+
+### Scenario A2: Billed in arrears with a minimum spend requirement per month
+
+The spend agreement with Acme requires the customer to spend a minimum amount in each Billing Period (monthly). Unused fees are charged per Billing Period when the consumption is below this level (use-it or lose-it). For this scenario, contract terms additionally include the following terms:
+
+* A minimum of &dollar;60 needs to be spent each month
+
+AwesomeCorp's consumption looks like this:
+
+* In the first month, the AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts). For this month, Acme charges &dollar;12 (ListCost of &dollar;15) for not meeting the monthly minimum
+* In the following 2 months, AwesomeCorp has usage at or above the minimum requirement
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A2 entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=1987749478#gid=1987749478&range=A25)
+
+Note the following details in the dataset:
+
+* A monthly charge representing the unused minimum monthly amount is charged during months 4 through 11 of the 12-month term
+* The final month has a charge that captures the overall unmet spend requirement for the 12-month contract. Alternatively, this could be provided as two charges, one for the unused portion of the final month, and one to capture the overall unmet spend requirement.
+
+## Scenario B: Prepaid contract
+
+For this scenario B, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* The charges will be billed in arrears using monthly invoices
+
+### Scenario B1: Prepaid with no minimum spend requirement per month
+
+Scenario B1 is similar to scenario A1 with the difference being that it's a pre-paid contract.
+
+**Example FOCUS dataset:** [Scenario B1 entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=1987749478#gid=1987749478&range=A50)
+
+Note the following details in the dataset:
+
+* A purchase record for the initial &dollar;1200 payment is present representing List, Billed, and Contracted cost of the purchase
+* The charge for the unused amount has a &dollar;0 BilledCost (since the total amount was billed with the prepayment). However, the charge captures the unused portion as an EffectiveCost.
+* The unused charge rows apply to the entire Charge Period the contract was signed for.
+* This scenario shows List Cost and Contracted Cost column double counting dynamic (described here in [ListCost](#listcost) and [ContractedCost](#contractedcost)) where either the [ChargeType](#chargetype) Purchase or Usage rows need to be excluded depending on the reporting scenario.
+
+### Scenario B2: Prepaid with a minimum spend requirement per month
+
+Scenario B2 is similar to A2 with the difference being that it's a pre-paid contract.
+
+**Example FOCUS dataset:** [Scenario B2 entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=1987749478#gid=1987749478&range=A58)
+
+Note the following details in the dataset:
+
+* A purchase record for the initial &dollar;1200 payment is present representing List, Billed, and Contracted cost of the purchase
+* The monthly charge for the unused amount has a &dollar;0 BilledCost (since the total amount was billed with the prepayment). However, the charge captures the unused portion as an EffectiveCost.
+* The final month has a charge that captures the overall unmet spend requirement for the 12-month contract. Alternatively, this could be provided as two charges, one for the unused portion of the final month, and one to capture the overall unmet spend requirement.
+* This scenario shows List Cost and Contracted Cost column double counting dynamic (described here in [ListCost](#listcost) and [ContractedCost](#contractedcost)) where either the Purchase or Usage rows need to be excluded depending on the reporting scenario.
diff --git a/specification/styles/base.css b/specification/styles/base.css
index 60d63943de..e17c3f4a55 100644
--- a/specification/styles/base.css
+++ b/specification/styles/base.css
@@ -75,11 +75,11 @@ h4 {
 }
 
 h5 {
-  font-size: 1.1em;
+  font-size: 1.2em;
 }
 
 h6 {
-  font-size: 0.9em;
+  font-size: 1.1em;
 }
 
 .title {


Reviews:
user: login: qquigley
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-19T13:59:31Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-20T00:47:36Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-22T11:04:01Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-22T16:59:09Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T18:18:59Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T18:57:00Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T20:29:58Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T20:44:28Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T20:55:13Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T22:19:41Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T22:23:10Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-23T22:30:00Z
user: login: shawnalpay
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-24T17:33:25Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T01:21:02Z
user: login: ijurica
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T01:21:27Z
user: login: ijurica
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T01:29:23Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T04:54:24Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T04:54:35Z
user: login: UdamDewaraja
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T04:55:42Z
user: login: rileyjenk
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T18:05:59Z
user: login: ljadvey
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-27T18:12:23Z
user: login: jpradocueva
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-28T00:50:58Z

Review comments:
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: qquigley
body: Should the Charge Period not be April 1st 2025 - March 31st 2026?
created_at: 2025-03-19T13:46:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
+  
+## Scenario A2: Invoice Up-front for a Quantity of a Service
+
+ACME Corp offers its customer the ability to purchase a fixed quantity of licenses for their service. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+On April 1st, 2025, ACME executes a contract and invoices AwesomeCorp &dollar;50,000 (Billed Cost) for a Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: qquigley
body: Same as above, should the Charge Period not be April 1st 2925 through March 31st 2026?
created_at: 2025-03-19T13:49:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
path: specification/appendix/saas_examples/spend_agreements.md
user: login: qquigley
body: Capitalization on `co`
created_at: 2025-03-19T13:55:17Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
+
+Note the following details in the dataset:
+
+* A single charge representing the total unused amount from the 12-month agreement is charged during the final month of the 12-month term
+
+### Scenario A2: Billed in arrears with a minimum spend requirement per month
+
+The spend agreement with Acme requires the customer to spend a minimum amount in each Billing Period (monthly). Unused fees are charged per Billing Period when the consumption is below this level (use-it or lose-it). For this scenario, contract terms additionally include the following terms:
+
+* A minimum of &dollar;60 needs to be spent each month
+
+AwesomeCorps consumption looks like this:
path: specification/appendix/saas_examples/spend_agreements.md
user: login: qquigley
body: Apostrophe AwesomeCorp's
created_at: 2025-03-19T13:57:18Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
path: specification/appendix/saas_examples/spend_agreements.md
user: login: qquigley
body: Apostrophe AwesomeCorp's
created_at: 2025-03-19T13:57:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: UdamDewaraja
body: Good question.. In FOCUS the start date is inclusive, and the end date is exclusive. This applies to both BillingPeriod and ChargePeriod. 
created_at: 2025-03-20T00:42:32Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
+  
+## Scenario A2: Invoice Up-front for a Quantity of a Service
+
+ACME Corp offers its customer the ability to purchase a fixed quantity of licenses for their service. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+On April 1st, 2025, ACME executes a contract and invoices AwesomeCorp &dollar;50,000 (Billed Cost) for a Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: UdamDewaraja
body: Same as above. The *End dates are exclusive.
created_at: 2025-03-20T00:43:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: Good call. In this PR we unfortunately have to have two people's changes and we're hoping to preserve commit history. I will keep these open and add them as a single change at the end (along with any other comments and feedback people provide)
created_at: 2025-03-20T00:46:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
+
+Note the following details in the dataset:
+
+* A single charge representing the total unused amount from the 12-month agreement is charged during the final month of the 12-month term
+
+### Scenario A2: Billed in arrears with a minimum spend requirement per month
+
+The spend agreement with Acme requires the customer to spend a minimum amount in each Billing Period (monthly). Unused fees are charged per Billing Period when the consumption is below this level (use-it or lose-it). For this scenario, contract terms additionally include the following terms:
+
+* A minimum of &dollar;60 needs to be spent each month
+
+AwesomeCorps consumption looks like this:
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: Same as above.
created_at: 2025-03-20T00:47:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: Same as above.
created_at: 2025-03-20T00:47:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: ijurica
body: ## Oversights

### PricingQuantity column

In one of the charges PricingQuantity set to 10 and it should be 4?

---

## Suggestions:

### PricingCategory

> * PricingCategory MUST be present in a [*FOCUS dataset*](#glossary:FOCUS-dataset) when the provider supports more than one pricing category across all SKUs.
> * PricingCategory MUST NOT be null when ChargeCategory is "Usage" or "Purchase" and [ChargeClass](#chargeclass) is not "Correction".

I understand (not happy about it, but I understand) that this column is mandatory only if the provider supports more than one pricing category across all SKUs, and from that perspective, this dataset is valid. Still, **I was wondering if we could fill it out.** 😄 

_**Note:** The same suggestion applies to all other SaaS Spend Agreement scenarios._

### SKU-related columns

Considering we are providing unit prices in these sample datasets, I believe we should also **fill out the SKU-related columns**.

Listing a couple of relevant normative requirements from the FOCUS 1.1 version:

> * SkuId column MUST be present in a FOCUS dataset when the provider publishes a SKU list.
> * SkuId MUST NOT be null when ChargeClass is not "Correction" and ChargeCategory is "Usage" or "Purchase".

> * SkuPriceId MUST be present in a [*FOCUS dataset*](#glossary:FOCUS-dataset) when the provider publishes a SKU price list...
> * SkuPriceId MUST NOT be null when ChargeClass is not "Correction" and ChargeCategory is "Usage" or "Purchase",

> * Etc.

The requirements listed above are somewhat unclear, and one might interpret that these columns are mandatory only if SKUs and SKU prices are publicly published—i.e., if public price sheets exist.
In TF-2, we discussed this and agreed that **SkuId, SkuPriceId, etc., are relevant and therefore mandatory** not only when they are publicly available but also when a provider offers **custom price sheets** - since the consumer must be able to **verify unit prices**.

Even though the PR addressing the clarification of SkuId and SkuPriceId is still pending approval, I would argue that the existing wording of these normative requirements at least implies that these columns should be included in the sample datasets.

_**Note:** The same suggestion applies to all other scenarios (both Simple SaaS Agreements and SaaS Spend Agreement ._

---

## Discussion Topics

### List Cost in case of `End of contract unused fee`

I've been struggling with the **ListCost for Unused Usage** in the case of CSP's non-negotiated Commitment Discounts for a while, and I'll use this opportunity to ask the question because the **same concern arises here**.

In this use case, AwesomeCorp committed to spending $1,200 in exchange for a discounted unit price. In the end, they **overpaid** for that service, right? If they hadn't committed to $1,200, they would have spent $285 (19 * $15) and not $1,200.

I would expect **SUM(ListCost) - SUM(BilledCost)** to show that **waste of $915** ($1,200 - $285), but based on the sample data, it seems like they saved $57.

If we set ListCost for the 'End of contract unused fee' to 0, comparing the aggregated ListCost and BilledCost would outline the waste?

created_at: 2025-03-22T11:04:01Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: @ijurica Thank you so much for thoroughly reviewing the data. 

**Pricing quantity:**
I think I found the 3 places in the data where I incorrectly set the pricing quantity. Please comment on the cells in Google Sheets in the future so we can find them and resolve them easily. This is the advantage we get from using Google Sheets for the building of these sorts of datasets/examples, etc.

**Pricing Category**
Added

**SKU related columns**
Side note: The requirement is that the provider 'publishes' (it doesn't say publicly or privately) but sure, we could be more explicit in those requirements if people assume publish as publicly publish. Either way, its a nullable column because smaller vendors may not have a published price (it could be a negotiated price from the start).

On the topic of examples providing every detail, I'm split on this. I think there are a lot of details we would want to add in each example (the content in the spec) if we want to reflect those details in the tabular data as well. Some of those details aren't very relevant to the example, at which point it could become a distraction both in the spec example description and in the dataset. The other side of it is that we don't have a 'golden data set' for FOCUS linked to the spec for users to find these kinds of fully fledged data rows (though the dataset F2 hosts might be a good candidate). Open to ideas. 

In this case, I could easily add some random SKU IDs and SKU price ID values so something is populated, but I don't know if it serves a purpose unless we also tie it somehow to the example description. Maybe we could add a placeholder like <populate> to indicate the column should be populated (just it's not relevant for the example). Thoughts?

**List Cost for unused**
I'm not sure SUM(ListCost) - SUM(BilledCost) is how i would find waste. I would think the sum of 'unused' rows (which are only easy to find for commitment today, unfortunately) is the way to find the waste. 

In the case of pre-payments with no discounts (assume no negotiated and commitment discounts), List and Billed Cost for the purchase should add up to the sum of the corresponding non-purchase rows over that same period. In the case where you have negotiated discounts or commitment discounts, the differences would be the savings from those instruments (though you would have to factor in the 'waste'. 

The alternative is we put different values based on unused charges (which 1. we would have to define in a general way, 2. we need to define this behavior in the normative requirements for List/Contracted). Again, open to whichever way the group wants to proceed.
created_at: 2025-03-22T16:59:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: ijurica
body: #### List Cost for Unused  

When it comes to **List Cost for unused, I spoke too soon** - I’ve changed my mind in the meantime. 😄  

Instead of setting it to **0**, I believe we should fill out **ListUnitPrice**, **ContractedUnitPrice**, and **PricingQuantity** in all rows and stick to the formula:  
**ListUnitPrice × PricingQuantity = ListCost**.  

If we follow this approach, the **ListCost** value doesn’t add up in a series of records (usually the unused fee and pre-payment purchase). I’m not sure if that’s an oversight or something else?

I started adding a bunch of comments to the **[1.2 SaaS Examples - Data samples from AIs](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023)** sheet based on this assumption - maybe that's a waste of time?  

@UdamDewaraja @rileyjenk  – are these oversights, or is there a specific reason why **ListCost = ContractedCost** applies to those records?  

_Note: Question/suggestion applies to all other SaaS Spend Agreement scenarios._
created_at: 2025-03-23T18:18:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: ijurica
body: ### Scenarios and Accompanying Sample FOCUS Datasets Completeness  

I believe it would be very useful to provide fully valid datasets with all charge records relevant to each scenario.  

#### SKU-related and all Other FOCUS columns

In other words, we should include all FOCUS columns (except perhaps those related to Capacity Reservation, assuming Acme Co doesn't support that concept) and populate them in a way that meets all normative requirements. And yes, I’m aware that we would need to invent values for some columns - for example, SKU-related columns.  

#### Implied charge records

I’ve noticed that in some scenarios (or datasets), we omit usage or purchase records if they already appear in a dataset associated with another, previously mentioned scenario, relying on the end-user to recognize which records should also be present in the current scenario. I believe the UX would be better if each dataset included all corresponding **Purchase**, **Usage**, and **Unused Usage** records. 

#### Purpose

Such completed datasets could be loaded alongside the sample dataset from the **[Sandbox](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS-Sample-Data)**, allowing users to run **Supported Features Queries** and **Use Case Queries**. It would also be useful for us… (Putting the FOCUS spec to the test!)

---

That being said, **I don’t think this is a show-stopper for merging this PR** into `working_draft`. We can refine this during the **Consistency Review** phase once we have a finalized set of columns for **FOCUS 1.2**. 🙂

created_at: 2025-03-23T18:56:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
+  
+## Scenario A2: Invoice Up-front for a Quantity of a Service
+
+ACME Corp offers its customer the ability to purchase a fixed quantity of licenses for their service. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+On April 1st, 2025, ACME executes a contract and invoices AwesomeCorp &dollar;50,000 (Billed Cost) for a Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
+
+**Example FOCUS dataset:** On April 1st 2025, Acme Corp provides the following FOCUS dataset for the above transaction: [Invoice up-front entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A11)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 to April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement is charged in the first invoice. Billed Cost and Effective Cost are both realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge provided includes a ListUnitPrice for the licenses and a Pricing Quantity.
+
+## Scenario A3: Additional Purchase Records Provided in the SaaS Provider's FOCUS Data
+
+On June 1st 2025 ACME provides the following records due to AwesomeCorp's &dollar;1,000 mid-contract purchase of an additional 10 licenses for the same Charge Period (April 1st 2025 to April 1st 2026).
+
+**Example FOCUS dataset:** [Additional license purchase entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A14)
+
+Note the following additional details in the dataset:
+
+* The Charge Period is still April 1st 2025 to April 1st 2026. The Billing Period is now the month of June 2025 (when the additional licenses were ordered) and therefore will appear in the June 2025 invoice.
+
+## Scenario B: Billed in Arrears for a Quantity of a Service
+
+Similar to Scenario A above, ACME Corp offers its customer the ability to purchase their service with a fixed quantity of licenses. However, in Scenario B, ACME issues the invoice at the end of the usage period.
+
+On April 1st, 2026, ACME invoices AwesomeCorp &dollar;50,000 (Billed Cost) for the Charge Period of April 1st 2025 to April 1st 2026. As there is no negotiated discount, List Cost of the purchase is also &dollar;50,000.
+
+**Example FOCUS dataset:** [Billed in arrears entries](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A17)
+
+Note the following additional details in the dataset:
+
+* The Charge Period is April 1st 2025 to April 1st 2026. The Billing Period is now the month of March 2026 (since this charge is invoiced as of the last month of the Charge Period).
path: specification/appendix/saas_examples/simple_agreements.md
user: login: ijurica
body: When I compare the description and the dataset, I see a mismatch in BillingPeriodStart and BillingPeriodEnd.

If we say "The Billing Period is now the month of March 2026 (since this charge is invoiced as of the last month of the Charge Period)", I believe the data in the dataset needs to be adjusted.

**Current:**

- BillingPeriodStart: 2026-04-01
- BillingPeriodEnd: 2026-05-01

**Suggested fix:**

- BillingPeriodStart: 2026-03-01
- BillingPeriodEnd: 2026-04-01
created_at: 2025-03-23T20:29:58Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: ijurica
body: Considering this is a Purchase charge record and the provider obviously supports unit pricing, I believe we must provide Unit Prices, PricingQuantity, PricingUnit, etc.

* [List|Contracted]UnitPrice MUST NOT be null when [ChargeClass](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/specification/columns/contractedunitprice.md#chargeclass) is not "Correction" and [ChargeCategory](https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/specification/columns/contractedunitprice.md#chargecategory) is "Usage" or "Purchase"
created_at: 2025-03-23T20:44:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: ijurica
body: I noticed that **BilledCost is set to 10,000**, while **EffectiveCost is set to 50,000**, the same as ContractedCost and ListCost.
I assumed that the same discounts should also be applied to EffectiveCost, meaning it should match BilledCost, not ListCost and ContractedCost.
created_at: 2025-03-23T20:55:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: **List Cost and Unused**

@ijurica I've added comments in the spreadsheet directly explaining why I don't think unit prices and negotiated discounts apply to unused charges of a spending commitment. Curious to get other peoples thoughts as well.

**Implied charge records**

Where's the Implied charge records? We need to fix that if thats the case. Would be helpful to get what specific places. I assume you mean scenarios [A1 and A2](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=1987749478#gid=1987749478&range=A11) in spend commitments examples? 

In this case, its billed in arrears, and there's no up-front purchase - just an agreement to spend that amount over the following year. It's not that dissimilar to a no-up-front Savings Plan. Happy to update if that's not the correct representation.

**Data completeness in examples / SKU etc.**

I think having FOCUS datasets that are complete is a different from targeted examples that are trying to show a particular scenario. Otherwise examples are going to be filled with a lot of useless details that make it hard for people to understand what things are relevant and what they should pay attention to. This isn't about putting a value in SKU or any other column. When we put values, it should tie into the example. If it doesn't, and is not necessary for explaining the example, my opinion is its better kept out of the example (both the example description / requirements and also the dataset).

created_at: 2025-03-23T22:19:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: UdamDewaraja
body: Argh, sorry copy paste issue. Fixed. Thanks for closely looking!
created_at: 2025-03-23T22:23:10Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: UdamDewaraja
body: I think I was trying to model the simplest/most basic scenario here.. where a provider has a charge for a service where it's just a price. There's not a unit price that was published, just an agreed-upon price that a vendor and a customer agree to. As unlikely as it might seem, smaller vendors work this way - They just have a 'contact us' as the price for the service and based on some factors, determine a price for the 'thing' you're buying.
created_at: 2025-03-23T22:30:00Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: shawnalpay
body: @ijurica Please review and resolve if the data looks good to you now!
created_at: 2025-03-24T17:33:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: ijurica
body: **Resolved:**

- **Implied charge records:** My mistake. I clicked 'Remove duplicate records' to remove the empty rows before I marked which scenario each row belongs to.
- **Data completeness in examples - SKU etc.:** @UdamDewaraja I hear you. This is out-of-scope for this PR.
  - We can later use these CSVs to prepare the "completed datasets" so that we can run/test Supported Features Queries and Use Case Queries, etc. However, that is unrelated to this PR.

**Can be addressed/resolved in the Consistency Review:**

- **List Cost for Unused:** I believe we can and should discuss and address this in the Consistency review. We could either adjust some of the normative requirements to accommodate what @UdamDewaraja is suggesting, or adjust the samples to ensure they are fully aligned with the requirements.
  - BTW, @UdamDewaraja did you add the comments to the old sheet? 😄 
  - Created AI #857 to further discuss and address this in the Consistency Review - hope that's ok

---

@UdamDewaraja feel free to resolve this conversation 
created_at: 2025-03-27T01:21:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,76 @@
+# Simple SaaS Agreements
+
+Many SaaS providers provide simple contract terms, therefore don't need to support complex scenarios like spend commitments or pricing strategies in their billing data.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for simple SaaS agreement scenarios (these scenarios may not be specific to SaaS agreements only).
+
+## Scenario A1: Invoice Up-front for a Purchase of a Service
+
+ACME Corp allows its customers to purchase their service for a term (in this case, a year) for a &dollar;10,000. ACME provides AwesomeCorp with a single invoice for their usage. ACME does not provide detailed cost and usage reports to AwesomeCorp throughout the Charge Period after the initial purchase.
+
+Given that ACME does not charge based on or track usage, its usage details are irrelevant to this scenario.
+
+**Example FOCUS dataset:** [Simple invoice up-front for service](https://docs.google.com/spreadsheets/d/1kQTDK3Sk9BnNcn6Ovyaa37T1aMaXfHaDahsuk1Notn4/edit?gid=694253803#gid=694253803&range=A8)
+
+Note the following details in the dataset:
+
+* The Charge Period is April 1st 2025 - April 1st 2026. The Billing Period is the month of April 2025 (when the licenses were ordered) and therefore will appear in the April invoice.
+* A single charge representing the total payment for the 12-month agreement (&dollar;10,000) is charged in the first invoice. BilledCost and EffectiveCost are realized in the same record since detailed usage records will not be provided during the 12-month period to realize amortized portions of this up-front payment.
+* The single charge record does not include a List Unit Price, Pricing Quantity, or SKU-related information. Alternatively, the Pricing Quantity could have been set to 1, and the List Unit Price could be the same as the total charge.
path: specification/appendix/saas_examples/simple_agreements.md
user: login: ijurica
body: I think this also falls into the category of "can and should be discussed and addressed in the Consistency review" (either by adjusting some of the normative requirements or by modifying the sample data).

@UdamDewaraja feel free to resolve this conversation.
created_at: 2025-03-27T01:29:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
+
+Note the following details in the dataset:
+
+* A single charge representing the total unused amount from the 12-month agreement is charged during the final month of the 12-month term
+
+### Scenario A2: Billed in arrears with a minimum spend requirement per month
+
+The spend agreement with Acme requires the customer to spend a minimum amount in each Billing Period (monthly). Unused fees are charged per Billing Period when the consumption is below this level (use-it or lose-it). For this scenario, contract terms additionally include the following terms:
+
+* A minimum of &dollar;60 needs to be spent each month
+
+AwesomeCorps consumption looks like this:
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: Fixed
created_at: 2025-03-27T04:54:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: Fixed.
created_at: 2025-03-27T04:54:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,89 @@
+# SaaS Spend Agreements
+
+Many SaaS providers support billing models that allow (or in some cases require) consumers to agree to an amount to spend over a period. In some cases, customer receive a negotiated discount for usage during that period in exchange for the spend agreement. Spend agreements can have different payment models like billing in arrears or pre-paid contracts and may impose minimum spend requirements for parts of the agreement.
+
+The scenarios described below illustrate how a FOCUS-compliant dataset should look for various spend agreement scenarios.
+
+## Baseline Scenario
+
+The following baseline conditions apply to the scenarios described below:
+
+* AwesomeCorp has signed an agreement with SaaS provider Acme Co to use their database services
+* On April 1 2025, AwesomeCorp agrees to spend &dollar;1200 (post-discounts) in the upcoming 12-months
+* AwesomeCorp receives a 20% negotiated discount in return for the commitment
+* Acme co calculates the spend counted against the agreements after discounts (like the negotiated discounts). Other providers may use the cost after discounts i.e., using List Cost for calculating the spend commitment.
+
+## Scenario A: Billed in arrears
+
+For this scenario A, contract terms include the following terms in addition to the baseline scenario mentioned above:
+
+* All charges will be billed in arrears at a monthly frequency
+
+### Scenario A1: Billed in arrears with no minimum spend requirement per month
+
+For this scenario, contract terms additionally include the following terms:
+
+* Committed spend can be used anytime within the 1-year term
+
+AwesomeCorps consumption looks like this:
+
+* In the first month, AwesomeCorp uses &dollar;48 of services (4 server hours). This usage has a List Cost of &dollar;60 (before discounts)
+* In the following 2 months, AwesomeCorp has some more usage
+* For the final 9 months, AwesomeCorp does not use Acme services
+
+**Example FOCUS dataset:** [Scenario A1 entries](https://docs.google.com/spreadsheets/d/1H69HmngVv-mKpFR-sveY-fSAdR49syqQd7AKOPPQ64A/edit?gid=1740845023#gid=1740845023&range=A15)
path: specification/appendix/saas_examples/spend_agreements.md
user: login: UdamDewaraja
body: @ijurica which comments? I deleted the old sheet and updated links to use only the new sheet
created_at: 2025-03-27T04:55:42Z
author_association: CONTRIBUTOR

PR comments:
user: login: shawnalpay
created_at: 2025-03-07T17:00:44Z
body: @UdamDewaraja to coordinate with @gparker-at-sf and @rileyjenk to get commits from #688 moved over to here.
author_association: CONTRIBUTOR
user: login: shawnalpay
created_at: 2025-03-07T20:05:28Z
body: Marking this PR as Draft until #831 is complete.
author_association: CONTRIBUTOR
user: login: jpradocueva
created_at: 2025-03-27T18:27:59Z
body: PR Approved by Members' group on Mar 27.
author_association: CONTRIBUTOR
user: login: jpradocueva
created_at: 2025-03-28T00:50:14Z
body: As per Udam's advice, this PR—approved by the Members in the March 27 call—is merged by creating a `commit` rather than `squash & merge`. This is to preserve George's work.  
author_association: CONTRIBUTOR