Finance Key Concepts
The Finance module calculates values for digital deal created in the Sales module. Therefore, some understanding of the Sales module and the line items within it is needed to understand the Finance module. To see the terminology used within this topic, please access Sales Key Concepts.
In this topic, you can find more about:
Invoice Values
The Finance module calculates three main fields for each invoice line item:
-
Net Invoice Amount is the monetary value you expect your customer to pay you for the line item.
-
Invoice Units are the number of units/quantities (impressions, clicks, actions, etc.) you show the customer on the invoice. When using terms based on delivery data, what metrics to use are based on the Unit Type field set for the deal line item in the Sales module.
-
Recognized Revenue is the monetary value you book as revenue internally.
The system calculates several other values (Cumulative, Invoice level sums, Gross, Remaining, Differed), but all these other values are in some way based on the above three values and those set from the sales line item.
Capping
Capping is a system setting available for the three main calculated fields (Net Invoice Amount, Invoice Units, or Recognized Revenue) that says whether they can exceed the Sales goals per line item. By default, capping is on and enforced for all three of these fields. Each field has a separate capping setting, in case you want to enforce this for some fields but not others. For example, you likely need to always enforce it for the Net Invoice Amount you bill but may want to allow exceeding the cap when showing the Invoice Units on the bill or for internal revenue reporting.
-
Net Invoice Amount capping means the Net Invoice Amount across all invoices for the same line item cannot exceed that line item’s Net Cost from the Sales module. This is also used for the Gross Invoice Amount which caps against the line item Gross Cost.
-
Invoice Units capping means the Invoice Units across all invoices for the same line item cannot exceed that line item’s Quantity from the Sales module.
-
Recognized Revenue capping means the Recognized Revenue across all invoices for the same line item cannot exceed that line item’s Net Cost from the Sales module.
Capping can be overridden in two places:
-
With Invoicing Organization Settings you can set for all the organization’s invoices whether to override the caps and allow more than the Sales contracted goals.
-
Within a Product or Package, on the Finance Settings pane, you can set for a specific product or package whether to override the organization and allow or not allow more than the Sales contracted goals.
Capping is always per line item and never per deal or invoice. With packages, under delivery in one line can be made up by over delivery in another line within that same package. However, this is NOT applied at the deal or invoice level.
Cap overrides are set per invoice line at the time an invoice line is created or updated based on the Sales module workflow. If you change an organization’s or product’s capping override setting, the change is not reflected on existing invoice data at that time. However, any new or modified line items will reflect the current cap settings at the time the deal completes the Sales workflow. In a future release, the Finance module will flag any violations that might occur based on the cap setting changes. Locked invoices are never affected by changes in the cap settings
Invoice Schedule
An invoice schedule breaks up line item goals across the different invoices associated with a deal, and it specifies the invoice terms (basis calculations) used for each line item. For example, the invoice terms determine whether to invoice based on what was expected to serve (contracted), what actually served from the primary production system (primary performance), or what actually served according to a third-party or rich media production system (third-party performance).
Invoice Terms
Invoice terms are the calculation basis used to determine the Net Invoice Amount, Invoice Units, or Recognized Revenue. At the Invoicing Organization level, administrators set default terms for the amount, units, and revenue that vary based on the Cost Method.
-
Amount Terms set how the system calculates the Net Invoice Amount and by extension the Gross Invoice Amount (which is based on the net). Administrators can set a default for each Cost Method as part of the Invoicing Organization and this default is used in the Sales module when line items are first created. If the Finance Summary tab is enabled on the Sales Workspace, then Sales module users can override those terms.
Note: If Sales users do not override terms, then changing the Cost Method can change the terms based on the organization's defaults, but if a Sales user has changed the terms, then changing the Cost Method does not reset terms. Changing the invoicing organization does not automatically reset default terms.
-
Unit Terms set how the system calculates the Invoice Units. Administrators can set a default for each Cost Method as part of the Invoicing Organization and this default is used in the Sales module when line items are first created. If the Finance Summary tab is enabled on the Sales Workspace, then Sales module users can override those terms.
Note: If Sales users do not override terms, then changing the Cost Method can change the terms based on the organization's defaults, but if a Sales user has changed the terms, then changing the Cost Method does not reset terms. Changing the invoicing organization does not automatically reset default terms.
-
Revenue Terms set how the system calculates the Recognized Revenue. Administrators can set a default for each Cost Method as part of the Invoicing Organization and this is used when invoices are created. Sales users cannot override this, but it can be overridden based on product or package settings.
A user in Finance can further override the terms from the organization, Sales, or Product module. If a Finance module user overrides the terms for an invoice line, further changes to the terms in other modules are ignored. Terms can never change while an invoice is locked. If a user in Finance did not override terms, then if the terms change in Sales as part of a revision, the terms update and values recalculate when deal completes its revision workflow unless the invoice is Prior_Locked or Locked.
The Net Invoice Amount, Invoice Units, and Recognized Revenue values for a single line item can all use different invoice terms. For example, you may want the Net Invoice Amount to reflect a contracted value regardless of delivery while still using actual delivery for the Invoice Units and Recognized Revenue.
The following terms are supported at this time.
Contract - Pro-rated Daily
Invoice values are based on contracted pre-defined goals rather than actual performance delivery data. Delivery is still gathered and visible in the Finance module, but it does not affect the invoice value. Instead, invoices are based on proportionally dividing a line item based on the number of days it runs in each period.
For example, consider the following line item billed on a Gregorian calendar.
|
Field |
Value |
|---|---|
|
Line item Start Date |
June 18 |
|
Line item End Date |
September 15 |
|
Quantity (Units) |
180,000 |
|
Net Unit Cost |
$5 |
|
Total Net (Amount) |
$900 |
Daily prorated values are determined based on the Net Cost and Quantity divided by the line length (days).
|
Field |
Value |
|---|---|
|
Total Days |
90 |
|
Daily pro-rated Quantity (Units) |
2000 = Quantity / Total Days = 180,000/90 |
|
Daily pro-rated Net (Amount) |
10 = Total Net / Total Days = 900/90 |
The monthly breakdown is then calculated.
|
Period |
Days |
Units |
Amount |
|---|---|---|---|
|
June (18 – 30) |
13 |
26,000 |
$130 |
|
July (1 – 31) |
31 |
62,000 |
$310 |
|
August (1 – 31) |
31 |
62,000 |
$310 |
|
September (1 -15) |
15 |
30,000 |
$150 |
In the export and some areas of the system, these terms are labeled as:
prorated
When dividing values on to periods, units are truncated to a whole number and amounts or revenue are truncated to four decimal places. Anything remaining is divided across periods starting with the period that has the most days. Then periods with the same number of days are ranked based on which comes first in time. For example, a line that runs across all of June, July, and August with a 100 quantity is divided as 33, 34, 33. July gets the extra one, because it has more days than June and because August comes after July.
Note: The cancel line item feature in the Sales module does not automatically change the Quantity, so is not recommended when using contracted terms, unless Sales users will also change the Quantity.
Contract - Straightline By Billing Period
Invoices are based on contracted pre-defined goals evenly dividing a line item between its billing periods, regardless of how many days the line item runs in each period. Delivery is still gathered and visible in the Finance module, but it does not affect the invoice value.
For example, consider the following line item billed on a Gregorian calendar.
|
Field |
Value |
|---|---|
|
Line item Start Date |
June 18 |
|
Line item End Date |
September 15 |
|
Quantity (Units) |
180,000 |
|
Net Unit Cost |
$5 |
|
Total Net (Amount) |
$900 |
Even billing period values are determined based on the Net Cost and Quantity divided by the number of periods
|
Field |
Value |
|---|---|
|
Total Periods |
4 |
|
Units Per Period (Units) |
45,000 = Quantity / Total Periods = 180,000/4 |
|
Amount per Period |
$225 = Total Net / Total Periods = 900/4 |
The monthly breakdown is then calculated.
|
Period |
Days |
Units |
Amount |
|---|---|---|---|
|
June (18 – 30) |
13 |
45,000 |
$225 |
|
July (1 – 31) |
31 |
45,000 |
$225 |
|
August (1 – 31) |
31 |
45,000 |
$225 |
|
September (1 -15) |
15 |
45,000 |
$225 |
In the export and some areas of the system, these terms are labeled as:
straightline
When dividing values on to periods, units are truncated to a whole number and amounts or revenue are truncated to four decimal places. Anything remaining is divided across periods starting with the earliest period in time. For example, a line that runs across all of June, July, and August with a 100 quantity is divided as 34, 33, 33. June gets the extra one, because it is first period in time.
Note: The cancel line item feature in the Sales module does not automatically change the Quantity, so is not recommended when using contracted terms, unless Sales users will also change the Quantity.
Primary Performance
Note: Primary Performance is also referred to as Publisher Performance or First Party Performance.
Values are based on actual performance delivery data from the primary production system where the ads are trafficked (e.g., GAM, FreeWheel). The units are taken directly from performance numbers imported into AOS. This is typically impressions, but the actual metric is based on the deal line item’s Unit Type field. Operative can customize AOS to support any whole number metric you can provide as the Unit Type. The amount of revenue is calculated by applying the line item’s Net Unit Cost to performance delivery details based on the Cost Method.
-
For CPM, vCPM, and Flat Rate Impressions, it is:
(Delivery/1000) * Net Unit Cost
-
For SOV-Flat Rate, Flat Rate, or SOV Flat Rate line items set to invoice on performance are invoiced as zero by default. Therefore, it is best to set those line items to be billed on a contract basis.
-
For all other Cost Methods, it is:
Delivery * Net Unit Cost
When considering the performance numbers, capping is applied by default to ensure they do not exceed the contracted goals set in Sales unless capping is overridden in the System Configuration or Product module.
When invoicing on the parent in a package, Net Invoice Amount or Recognized Revenue is first calculated for each child line item on its own without capping. The total for the package is then determined based on summing the total for all the children in the period, and capping is applied to that parent total if applicable. This properly weights child line items that may have different unit costs and lets you calculate performance values when line items have different cost methods. Be aware that packages can make up for underperformance in one line item with overperformance in another line item regardless of the value of those lines. If this is a concern, you should invoice based on the children and aggregate outside AOS.
For Packages, Invoice Units are zero when child line items have different cost methods.
Delivery outside the line item dates in AOS that might occur in the production system is captured by AOS but is not visible or considered within the Finance module.
In the export and some areas of the system, these terms are labeled as:
publisher_performance
Third-Party Performance
Values are based on actual performance delivery data from a third-party (normally an agency) production system where ad performance is tracked (e.g., DCM, Sizmek). When using Third-Party Performance, you must set each line item’s Billable Third-Party Server field in the deal to the third-party system where the numbers come from.
In the export and some areas of the system, these terms are labeled as:
thirdparty_performance
Other than the source of the numbers, Third-Party Performance behaves the same as Primary Performance and its calculation details are the same.
Performance
When calculating values, this uses Third-Party Performance first but falls back to using Primary Performance if there is no Third-Party Performance or Third-Party Performance is zero..
IF Third-Party Performance > 0, use Third-Party Performance
ELSE use Primary Performance
This lets the presence or lack of third-party data determine whether to use it or not. Also, since third-party data is only used when a Billable Third-Party server is set for a line item, you can effectively choose whether to use third-party data based on whether there is a Billable Third-Party Server. Capping is applied unless it is overridden.
The choice to use third-party data is made per period and not per day. If even one day for a line item has third-party data for the billing period, third-party is used, even if primary delivery is available for more days.
Units Sync
Units Sync link the Net Invoice Amount or Recognized Revenue to the Invoice Units for cases when you do not want them to be independent. AOS is designed so that the Invoice Units, Net Invoice Amount, and Recognized Revenue are independent from each other with separate Unit Terms, Amount Terms, and Revenue Terms defining their calculations. This provides flexibility for different finance needs such as showing actual impressions for Invoice Units while using a fixed contracted dollar value for the Net Invoice Amount.
When using Units Sync terms, when Invoice Units change, either manually in the Finance module (Editing Invoice Details) or based on delivery or deal revisions, AOS automatically recalculates the Net Invoice Amount or Recognized Revenue based on the changed Invoice Units, Cost Method, and Net Unit Cost.
-
For Amount Terms, setting Units Sync tells AOS to use the Invoice Units value to calculate the Net Invoice Amount and Gross Invoice Amount as well as any derived values.
-
For Revenue Terms, setting Units Sync tells AOS to use the Invoice Units value to calculate the Recognized Revenue as well as any derived values.
-
For Unit Terms, setting Units Sync calculates Invoice Units as zero. Don’t set this.
For the amounts and revenue, Units Sync calculations are the same as when using performance terms, but the Invoice Units are used instead of actual delivery.
-
When Unit Terms are set to use one of the performance, amount and revenue normally are the same as if the Amount Terms or Revenue Terms were also set to use performance. However, if you change the Invoice Units or Unit Terms, then the amounts and revenue also change without having to also change the Amount Terms or Revenue Terms.
-
When Unit Terms are contacted, there can be rounding differences for the amount and unit compared to if the Amount Terms or Unit Terms were contracted.
-
Since the calculations are the same as performance, you should not use Units Sync terms with the Flat Rate or SOV-Flat Rate Cost Method. Amount and revenue will be zero.
-
Units Sync terms do not supported the Various Cost Method, which is used when package children have different Cost Methods. Amount and revenue will be zero.
The main reasons to use Unit Sync are:
-
If you manually set the Invoice Units within the Finance module UI, AOS automatically updates the Net Invoice Amount and/or Recognized Revenue
Related fields derived from the units, amount, and revenue are recalculated only after you save. These include Gross Invoice Amount, Cumulative Units Invoice, Cumulative Net Invoice Amount, Cumulative Recognized Revenue, Unrecognized Revenue, Deferred Revenue, and Remaining Amount..
-
If the organization defaults Amount Terms as Units Sync, then Sales users only need to set the Unit Terms on the Finance Summary tab. The Net Invoice Amount will automatically be based on those terms, so users do not need to set both. However, when the Cost Method is Flat Rate or SOV-Flat Rate, they will still want to set Amount Terms. In addition, the Finance Summary tab will not show the period breakdowns for the amount. Also, in some cases when lines run in multiple periods, for contracted terms, there may be slight rounding differences between when the system prorates or straight lines the Net Cost and Quantity separately versus when it first divides the Quantity and then uses those divisions to calculate the amount or revenue.
Invoiced
Invoice terms are only available for Recognized Revenue, and they tell the system to calculate as:
Recognized Revenue = Net Invoice Amount
However, capping can still apply to the Recognized Revenue independent of the Net Invoice Amount, so the Recognized Revenue can be less than the Net Invoice Amount in some rare cases.
Manual
Values are not calculated by AOS. Users must manually type them in. The system will still enforce capping if enabled, but it will not attempt to calculate the values. If you manually type in a value where the system was using another invoice term previously, that will automatically set its invoice terms to manual as explained in Editing Invoice Details.