Skip to main content
Top

Billing Codes and Billing Rates

Russell Johnson
  • Updated

Billing Rates are the values assigned to transactions which multiply by units and quantities to calculate a billing amount for an invoice.

NOTE: This document describes the behavior of a Billing Code and Billing Rates on a Transaction. Unless otherwise noted, the behavior is the same for Bid Details.

Billing Code

The Billing Code determines how a transaction is billed. Selecting a Billing Code defines the rate and type of unit – each, hourly, etc. – and can also determine the cost per unit as well as how units are calculated. A transaction may exist without a billing code, but it will not calculate cost or be invoiced without one.

Billing Codes are composed of a main record and one or more Rate Sets. The main, or header, record stores general values for the code. A few key values are:

  • Billing Code - the 10-digit code that may be entered on a transaction.
  • Description - what will be seen in reports/ invoices. It may be overwritten on the transaction, but this is used as the default value.
  • Pricing - how the code will calculate rates. It could be one rate per unit, different rates by the number of units, or a few other methods. Refer to Pricing below for more information.
  • AR Category - the category within Accounts Receivable, which determines the GL Account to which the amount from the transaction will be posted.
  • Tax Mode - whether the code is taxable, not taxable, or only the markup amount is taxable.
  • Tax Code
    • If taxable, identifies the tax code that defaults to the transaction. This determines the percentage of tax. It can be overwritten at the transaction level.
    • NOTE: A Tax Code can also be taxable or not. Tax Mode defines if a tax code should be used at all. The Tax Code decides the percentages. So a code could be set to taxable per the Tax Mode but the Tax Code selected may not have any percentages set up.
  • Unit Type - how the code works with the Unit on a transaction, depending on the Unit Type’s Base Unit of Measure (Base UoM). Some can be defined to set the transaction/detail unit based on the date/time of the transaction, by minute, hour, day, or week. Other Base UoM don’t determine how to calculate Units.
    • The Unit Type description or code displays on most reports alongside the Unit to indicate what the number means: hours, minutes, each, GB, MB, etc.
  • Minimum - the lowest number of Units that should be assigned when a Billing Code is added to a transaction or detail. The system generates a warning if the user sets a number lower than the Minimum.
  • Increment - the unit increment, e.g., 5 minutes, 15 minutes, 1 hour, 1 day, etc.
  • Internal - when selected/checked, transactions can calculate costs but do not store rates or display on invoices.
  • Comment - when selected/checked, transactions do not hold costs or rates; they are put on a transaction so that the Billing Description is present on the invoice.
  • Resource Billing / Resource Billing Cost Only - identify the code as a special kind that does not get assigned to a transaction or detail. These types of codes are assigned directly to a resource to define that resource’s personal rates. These rates then override those set up for the billing code on the transaction. More below.

There are other values, but the ones above are used or required most frequently.

Rate Cards

A Rate Card is a value that is assigned to an Order. In combination with each Billing Code, it determines which Rate Set to apply to a transaction.

Standard Rate Card

Each instance of the Platform must have a standard Rate Card. It is considered the default or base rate card and is where the system finds a rate when no other, more specific rate card applies.

The Standard Rate Card:

  • Created automatically (ID = 1), and should never be deleted.
  • Must always be Active.
  • Should not be associated with/limited to a specific Division or Work Group.
  • Each Billing Code should have a Rate Set defined for the Standard Rate Card, even if the rate and cost values are zero. Without it, there’s a chance the Billing Code won’t be able to find a rate.

Other Rate Cards

Other rate cards:

  • Created as needed, and can be deleted if necessary.
  • Can be set to Active for normal use or deactivated when they are no longer needed.
  • Can be associated with/limited to a specific Division or Work Group.
  • Billing Codes do not need Rate Sets defined for all Rate Cards, only those that differ from the standard.

Customer Discounts and Markups

  • In v10.2 and higher, sites may create customer-specific discounts and/or markups on rate cards. This allows for customer rates without creation of a separate rate card. Customer discounts and markups can be for the rate card in general or by AR Category, allowing, for example, a customer to be set up for standard rates except in the “travel” category.

Rate Sets

One or more Rate Sets are assigned to any Billing Code.

  • Each Rate Set is for a single Rate Card
  • All Billing Codes should have at least one Rate Set defined for the Standard Rate Card (ID=1), even if the Rate is zero. Without it, a Billing Code will be treated as a normal, single rate code (more under Pricing below) and will default to a rate of $0.
  • The requirements of the Rate Set differ based on the Pricing of the code. Meaning, a normal pricing billing code has different values than a ‘multiple OT’ or ‘weekly’ billing code.
    • NOTE: The standard layouts for Rate Sets are set up with visibility of certain sections by Pricing. Sites that wish to make custom layouts should be aware of this and know that not all fields available in the document are valid for every code.

Editing Rates

Keep the following in mind while editing and archiving rates:

  • If you edit a Rate Set, a NEW one is created rather than editing the old. This is for archiving purposes.
    • This is not immediately evident to the user, who will simply open the Rate Set, make edits, and save. Other than the ID of the Rate Set changing, everything else looks the same.
    • This is most important for sites that use methods other than Xytech services and APIs to pull rates from the system. Using the Rate Set ID will not always guarantee the correct Rate Set.
  • A new Rate Set is created on transactions and bid detail after rates are loaded and then changed, to keep them unique for the record.
    • This means that one Billing Code may have a Rate Set on the Standard Rate Card, another Rate Set for the same Billing Code on separate Orders – same base rates but some adjustments – and yet another for bid details.
    • There are fields that store the Trx No and Bid Detail No for these versions of Rate Sets.
  • There should only ever be one active Rate Set for any Billing Code per:
    • Rate Card
    • Bid Detail
    • Order transaction

Pricing

The pricing of a billing code is a combination of the Pricing value of the code and the values entered in a Rate Set. While the “normal” pricing is one rate per unit, other Pricing types allow for billing by volume, by number of hours (units) with a different rate after a certain threshold – i.e., overtime – or by week or month.

Once a Billing Code has been assigned a Pricing type, it cannot be changed.

Within the Rate Sets that define multiple values, multiple tiers of rates are defined.

A transaction or bid detail assigned a Billing Code with a multi-rate will show ‘MULTIPLE’ in the Rate field and also have a ‘Rates’ button to open the Rate Set.

Each pricing type allows for the definition of Cost 1 and Cost 1 per tier.

Normal

This is the default type of rate which allows for setting an amount to charge per Billing Unit.

Multiple OT

This type allows for billing one rate up to a certain amount of units, then another rate for units over that amount. This is the basic billing for labor resources that work “regular” time, “overtime”, “double time”, etc.

For each tier, the following can be defined:

  • Units: Start Unit and End Unit fields define the range. If the End Unit value is left alone, it will show ‘Unlimited’. At least one tier in each set must have this value as ‘Unlimited’, namely the last.
    • Start Unit is not editable. It will automatically be set to 0 for the first tier and then to a .01 value after the End Unit of the previous tier.
  • Rate, Cost 1, Cost 2: these match to values on the transaction or bid detail.

Example:

  • Tiers set up as follows:
    • Tier 1; 0-8 units; Rate $100
    • Tier 2; 8.01-12 units; Rate $150
    • Tier 3; 12:01-Unlimited units; Rate $200
  • Would bill as follows on a transaction with 15 units:
    • 8 units at $100 for $800
    • 4 units (8-12) at $150 for $600
    • 3 units (12-15) at $200 for $600
    • Billing total: $2000

Things to know:

  • Multiple OT can only account for Units on a single transaction. Meaning, if one transaction with the billing code is for 4 units and another one for the same day/date is for 5 units and the tiers are set up for 0-8 units and 8+ units, the second transaction will bill entirely within the 0-8 unit tier, not recognizing that 4 units had already occurred.
    • To cover the above scenario, Payroll Rules or Scheduling Counters must be used and WO Actual is a better option.

Volume

This type is designed for when items are being sold and the price per unit is less the more units being sold.

Unlike Multiple OT, this type will only bill from one tier, the one where the transaction unit falls in the range.

For each tier, the following can be defined (Note: these are the same base values as Multiple OT):

  • Units: Start Unit and End Unit fields define the range. If the End Unit value is left alone, it will show ‘Unlimited’. At least one tier in each set must have this value as ‘Unlimited’, namely the last.
    • Start Unit is not editable. It will automatically be set to 0 for the first tier and then to a .01 value after the End Unit of the previous tier.
  • Rate, Cost 1, Cost 2: these match to values on the transaction or bid detail.

Example:

  • Tiers set up as follows:
    • Tier 1; 0-10 units; Rate $10
    • Tier 2; 10.01-30 units; Rate $8
    • Tier 3; 30:01-Unlimited units; Rate $5
  • Transactions would bill as follows:
    • 8 units at $10 for $80
    • 15 units at $8 for $120
    • 40 units at $5 for $200

Things to know:

  • Since there is only one rate that applies per transaction, the transaction Rate will show rather than ‘Multiple’.

Weekly

This type was designed for rental sites that bill by the day, week, month, or year.

Unlike other types, this one has a pre-defined list of tiers that cannot be added to. Leaving rates as $0 will bypass use of tiers. 

For each tier, the following is defined:

  • Week Type
    • Daily: price per day lower than 7 days
    • Weekly: price per 7-day period
      • This amount will set a limit on the Daily prices. See Examples
    • Daily after first Week: price per day greater than 7 days but less than the next 7 days (i.e., between 7.01-13.99)
    • Monthly: price per calendar month or 4-week month
    • Annual: price per year
  • Rate and Costs

Example:

  • Tiers set up as follows:
    • Daily: $400
    • Weekly: $1000
    • Daily Rate after First Week: $300
    • Monthly: $3500
    • Annual: $0
  • Transactions would bill as follows:
    • 2 days: $800 (400 x 2)
    • 4 days: $1000 (400 x 4 = 1600, which is over 1000 so bill 1000)
    • 6 days: $1000
    • 8 days: $1300 (weekly 1000 for 7 days + (300 x 1 day after week))
    • 16 days: $2600 ((1000 for 14 days) + (300 x 2 days))

Things to know:

  • Units only apply to those within the range of the tier. Meaning, if the tier is 10.01-20.00 units and the transaction Billing Unit is 15 only 5 units will be applied to the Rate per unit.

Up To and Including

This type is a combination of a price per unit and a flat charge. This code covers situations where a customer should pay a price per unit as well as a surcharge. It can also cover a flat fee for a number of units, such as up to 5 units is $100 and anything over that is $20 a unit.

For each tier, the following can be defined:

  • Units: Start Unit and End Unit fields define the range. ‘Unlimited’ applies as with other Pricing.
  • Surcharge: This is a flat amount that will be billed on the transaction. This could be in addition to a price per unit or – if Rate is 0.00 – instead of a Rate.
  • Rate, Cost 1, Cost 2: these match to values on the transaction or bid detail.
  • Cost Surcharge: Same as Surcharge except for Costs. There is only one Cost Surcharge, not one for each of Cost 1 and Cost 2.

Example:

  • Tiers set up as follows:
    • Tier 1; 0-10 units; Rate $0; Surcharge $90
    • Tier 2; 10.01-20 units; Rate $0; Surcharge $150
    • Tier 3; 30:01-Unlimited units; Rate $10; Surcharge $200
  • Transactions would bill as follows:
    • 2 units at $90 surcharge
    • 8 units at $90 surcharge
    • 11 units at $150 surcharge
    • 18 units at $150 surcharge
    • 40 units at $200 surcharge plus $100 (10 x 10 units over 30)

Pass Thru

This type is the same as Normal except when linked to another application such as Purchase Order. If linked, the cost from the other application will be applied as a Rate per unit on the transaction.

Things to know:

  • A Pass Thru code can be assigned a Rate. It will function as a Normal billing code until/unless the transaction is linked.

WO Actual

This type is the same as Multiple OT except that each tier can be assigned an Actuals Action Code. Before or without posted Order Actuals, this type functions as a Multiple OT code. After actualization, each Actual row that is linked to the transaction will look for a Rate tier with a matching Action Code and will post units to it.

Things to know:

  • Time Card can be set up to automatically create and post actuals via Payroll Transactions. Action Codes are set up to match to Payroll Types, then actuals are created for the linked transaction based on which Payroll Transactions exist for the Activity.

RADs

Rate Attribute Definitions – aka ‘RADs’ – are used to expand the assignment of rates beyond per unit. RADs were initially intended to allow for various attributes within Media Orders to allow billing by source or target format, length, aspect, etc. Functionality was then expanded to allow billing by order and transaction attributes, such as Order Type or Group and Resource.

Each tier in a RAD setup looks for a particular value. That value will be matched to the specified table in the Order to determine if the RAD will be used for a transaction.

  • Pricing Document: Each RAD is particular to one of the three types of orders: Work, Media, or Transmission.
  • Entity: This is the table within the Order that is used to match, such as the header, Service Row, input source, target source, etc.
  • Attribute: this is the field within the table to match. This list is limited and finite. Not all fields are available.
    • Adding to this list is a feature request, not a gap.
  • Operator: This decides how values will match, e.g., equals, not equals, greater than, etc. Not every operator works with every Attribute.
  • Value: This will be text or a drop-down, depending on the Attribute. If a drop-down, this is a single-select.
  • More than one tier can be added for more than one Entity. All values must match for the Rate Set to apply.
  • For service rows within Media or Transmission Orders, a ‘Service’ match for the Service Row Entity must be included. Matches can’t be made without defining the Service.

One or more RADs may be assigned within each Rate Set.

Simple Example:

  • RAD1 for the Media order pricing document:
    • Tier 1
      • Entity: Service Row
      • Attribute: Service
      • Operator: Equals
      • Value: Service1
    • Tier 2
      • Entity: Service Row
      • Attribute: Format
      • Operator: Equals
      • Value: MP3
  • RAD2 is set up exactly the same except the Value on Tier 2 is MP4.
  • Billing Code MPFORMAT is set to Normal Pricing with 3 Rate Sets. One with a Rate of $100 with RAD1 and another with a Rate of $150 with RAD2. The third is for $50 with no RAD.
  • Billing Code used on transactions as follows:
    • Transaction not linked to any Service Row will use the Rate Set with no RAD. $50 per Unit.
    • Transaction linked to a Service Row for Service1 where Format is MP3 will bill at $100 per unit. RAD1.
    • Transaction linked to a Service Row for Service1 where Format is MP4 will bill at $150 per unit. RAD2.
    • Transaction linked to a Service Row for Service1 where Format is MP5 will bill at $50 per unit. No RAD.
    • Transaction linked to a Service Row for Service2 will bill at $50 per unit. No RAD.
  • If the third Rate Set with No RAD did not exist, there would be a billing issue since neither of the Rate Sets with RADs could apply. Because of this, it should be standard procedure to provide each Billing Code with a no RAD Rate Set so something can be applied when all others cannot.

RADs can be very complicated. To help with setup, Rate Query Builders are available. These are sets that can be defined to test values to see if the correct Rate Set is returned.

Unit Types

Unit Types are assigned to Billing Codes to define what the Billing Unit means – i.e., hourly, daily, each, etc. The Unit Type is then inherited on the transaction.

In setup, Unit Types have a ‘Base Unit of Measure’. Most of these are simply labels. But some have functionality, namely those that are “Scheduled”. Unit Types with these Base UoM look at the begin and end times of a transaction to calculate the Billing Units.

Special Codes

There are a few special types of Billing Codes

Resource Billing Codes

A code marked as Resource Billing is never assigned to a transaction. These codes are placeholders for rates that are specific for a Resource. These would be used when a site wishes to assign the same Billing Code to a transaction for the type of work, but each Resource using that Billing Code has a different billing rate.

An example for user would be a group of editors, each of whom have a different billing rate. For Scheduling purposes, each of the Resources should be in the same Group. For invoicing and billing purposes, it’s best to use the same Billing Code rather than different but similar billing codes per Resource.

Setup:

  • Add a Resource to a Group
  • Assign a Billing Code either to the Group or to the Resource within the Group
    • This Billing Code should have at least a base rate, even if it’s zero.
  • Create a Resource Billing Code for the Resource within the Group (separate field).
    • Lookup should filter to only find those that are Resource Billing Codes
    • Assign rates per the Resource. More than one can be created by the Rate Card.
  • The Pricing of the Billing Code and the Resource Billing Code should match.

When the Group and Resource are assigned to a transaction, the Billing Code should come from the Group or Resource in Group setup while the rates will come from the Resource Billing Code. There is no reference to the Resource Billing Code on the transaction.

Resource Billing Codes can also be cost-only. This means that the Rate will come from the Billing Code but the Costs will come from the Resource Billing Code.

Cost Only

Cost-only billing codes on a transaction will not show up on an invoice, but will hold cost values.

Comment

Comment Billing Codes are only descriptions. When assigned to a transaction, its Billing Description will show up as a line item on an invoice without a rate. No costs.

Code Groups

This allows for Billing Codes with different Unit Types to be grouped together. The most prevalent example is an hourly, daily, and weekly rate for the same service.

Once codes are grouped, one of them – the default – will be assigned to the Group or Resource in the Group. That code will be assigned to the transaction when the Group and Resource are selected. A special button will appear next to the code on the transaction that opens up a list that shows the user the other codes in the list. So, the hourly code could default but the user could search to find out the weekly or daily code instead.

Usage

Billing Codes are assigned to transactions or bid details. If the code holds a rate – i.e., it isn’t a cost-only or comment code – it will go through a billing hierarchy to determine what rate to assign to the row.

  • See ‘Billing Code / Rate Source Hierarchy’ for the steps the system follows. At a high level, the hierarchy looks for approved bids or deal memos, the rate card that applies to the order, and the dates and times of the transactions.
  • The underlying code

The Billing Code can be set up to default to the transaction:

  • By the Group
  • By the Resource in the Group. This overrides the Group code.
  • With Group Billing
    • This is a separate list defined within the Group.
    • This overrides both Group and Resource Billing Codes.

Billing Codes can also be loaded as part of a template or, in Media and Transmission Orders, via Service or Operation setup.

Transactions have Units and also have a Billing Quantity (Qty). These values will be multiplied as part of the calculation of the Billing Amount. For Billing Codes with multi-rate Pricing, the Unit is what determines


~~~

Was this article helpful?
0 out of 0 found this helpful
Return to top

Didn't find what you were looking for?

Submit a Ticket