QuotaPath calculates commissions from the data you already keep in your CRM, billing system, spreadsheets, and warehouse. This article explains how that data needs to be shaped to work.
The one rule that makes everything work: get the data into one object! This is the most important thing to understand about QuotaPath integrations.
Data Model
A compensation plan reads from a single object in a single system. Think of an "object" as one type of record: a HubSpot Deal, a Salesforce Opportunity, a QuickBooks Invoice, a row in a Google Sheet.
Every field a compensation plan needs for the commission logic (the deal owner, the amount, the close date, the won/lost status, anything you filter or pay on) has to live on that one object. If the data you need is spread across two systems, say the deal lives in HubSpot but the payment lives in QuickBooks, it can still work, but only if we can join those records together first and bring the needed fields onto one of them.
For that join to happen, you need a connecting ID: a shared value that exists on both records. For example, a custom field on each QuickBooks Invoice that stores the related HubSpot Deal ID. Without a connecting ID, the two objects can't be matched, and the data can't be combined.
The takeaway: before you can calculate commissions on data from multiple systems, that data has to be consolidated onto one object using a connecting ID.
Data Types
Deal Create (required)
The source QuotaPath uses to create commission records ("Deals"). One row in, one commission record out. It drives every compensation stage:
Closed Won: the commission has been earned and counts toward quota attainment
Pipeline: the commission could be earned
Closed Lost: the commission was not earned
Payouts Eligibility (optional)
Controls when an earned commission is actually paid out. You can release payouts based on:
Date fields: release set percentages as specific dates are reached (for example, 50% at invoice, 50% at payment)
Amount fields: release proportionally as payment amounts come in against the original deal value
Payouts Eligibility can live on the same object as Deal Create, or on a different object that we join in using a connecting ID.
Data Mapping
When you set up a plan, each data type is mapped to one object in one system. Any fields you need for dates, names, filtering, won/lost status, or payout eligibility are brought onto that object by the QuotaPath Solutions team.
If your data spans two objects, we pick the object to map to, confirm the connecting ID, and pull the other object's fields across.
Example: HubSpot and QuickBooks
Payouts become eligible once an invoice is generated in QuickBooks, and you've added a custom field to every QuickBooks Invoice holding the related HubSpot Deal ID (your connecting ID).
Map to QuickBooks Invoice | Bring over from HubSpot Deal |
Invoice amount | Deal Owner |
Use Payouts Eligibility by Amount | Deal Type |
Everything the plan needs now sits on the QuickBooks Invoice object.
Custom Fields
Sometimes the field you need for a compensation plan doesn't exist on your object yet. There are two ways fields get created, depending on where the source data lives.
Computed Fields
Computed fields are used when the data you need isn't already available on your object. The Solutions Engineering team creates these fields by pulling data from another object or system, joining records together, and transforming the results into a new field on your object.
Examples:
Looking up a Customer's ARR from another system
Combining multiple fields across objects into a single plan-ready value
Use a computed field when the information you need does not currently exist on the object.
Calculated Fields
Calculated fields are used when all of the required data is already on the object and you simply need to transform it. You can create formulas directly in QuotaPath to perform calculations, apply conditional logic, or derive new values from existing fields.
Examples:
Amount × Commission Rate
Applying different values based on Deal Type
Adding one month to a contract start date
Use a calculated field when all required inputs already exist on the object.
Rule of thumb: If you need to bring data onto the object from somewhere else, you'll need a computed field built by the QuotaPath Solutions Engineering team. If the data is already on the object and you just need to apply formulas or logic, use a calculated field in QuotaPath.