A SELA is a paper document. It lists products, quantities and rates, and it names the org each line is provisioned to. What it never tells you is whether any of it is actually being used.
Your org analyses tell you the opposite half of the story: who logs in, which licences are consumed, which profiles hold them — but they know nothing about what you agreed to pay for.
The contracts area exists to close that gap. It puts the paper side of the agreement next to the measured reality of the orgs, line by line, so that "we bought 4 000 of these" and "1 100 people actually use them" finally appear on the same screen — and so that every seat can be traced back to the business unit that should carry its cost.
Contracts live at the folder level, next to the graphs of the orgs they cover: open a folder and use Contract management. A folder usually holds several contracts (the live one, a draft renewal, past terms). Everything is edited in place and saved as you type.
Each contract has three screens: SKUs, Mapping and Business Units — the paper, the bridge, and the cost owner.
The first screen is the agreement as written: one line per contracted product, per org.
Sections by Group, Org or Product. Group mirrors the sections of your order form. Org regroups everything by the org it is provisioned to. Product aggregates the same product across every org, and lets you expand it to see the per-org detail. Sort by name, pricing or quantity, and collapse or expand everything at once.
Pricing. A line is either a Unit line (quantity × monthly fee) or a % add-on — a percentage of that org's net base, computed live from the lines it applies to and never accumulated on top of another add-on. Each line shows its value per month and per year, with a Price-list value (annual) total for the whole contract.
Usage lines. Metered items — the parts of the agreement billed on consumption rather than seats — sit in their own sections, Usage details by account and by org, with included quantity, rate, resulting value and term dates. They are kept out of the subscription total on purpose, because that is how they are billed.
Terms & rules. Renewals, swap rights, transfer clauses, entitlement exceptions: captured as free text, for reference. They are notes, not automation.
Contract settings (the Edit button) holds the name, order-form and agreement references, dates, capped fee, currency, and the linked graphs — the orgs of this folder that this contract covers. Duplicating or deleting a contract lives there too.
Nothing on this screen is derived from an org. It is your side of the negotiation, recorded faithfully — including the awkward parts, like a percentage add-on whose real cost you know but can't recompute.
A real SELA is a wall of Org IDs. On its own, an Org ID tells nobody anything.
Every SKU line carries the Org ID the product is provisioned to. The org's name is stored once, on the contract's org record — not repeated on every line. Open the Orgs drawer to review and name every Org ID the contract mentions.
Orgs in a SELA are not only Salesforce orgs: Heroku, Marketing Cloud, Quip and tenant identifiers all appear, and they are kept exactly as written.
Reconciliation with your graphs. When an Org ID matches the Org ID captured on one of the folder's analysed orgs, the two are linked automatically. The line then shows the graph name with a 📊 chip, with the raw Org ID kept alongside, and one click opens that org's analyses. The same org written in its 15- and 18-character forms is recognised as one org.
This is the step that turns the contract from a list of codes into a map of your estate — and it is what makes everything downstream possible: only a reconciled org can be compared against real licence data.
This is the heart of it. The Mapping screen is where a paper item meets the licences that actually exist in the orgs.
You don't map raw contract lines. On the SKU list, Map product promotes a product — every line bearing that name, across every org — into a mapped product. Only the products you care about are promoted, so the noise of a 350-line order form doesn't have to be mapped before the screen becomes useful.
For each mapped product, Edit mapping lists every org the product is provisioned to, and you pick one licence per org:
a reconciled org offers the licences, add-ons and entitlements found in its analysis, each shown with its provisioned and used counts, so you pick the right one with the evidence in front of you;
an org with no analysed graph takes a manually entered provisioned volume, so the picture stays complete even where you have no data.
The default view then answers the question the paper never could, one row per org:
Column | What it is |
Contracted | what the SELA says you bought |
Provisioned | what actually exists in the org |
Used | what people actually consume |
Utilisation | used ÷ provisioned |
Δ vs contract | provisioned minus contracted — over or under your entitlement |
Three numbers that live in three different worlds — a signed order form, an org's setup, and its real activity — finally on one line. Shelfware becomes visible. So does the opposite: a product provisioned beyond what was contracted.
Knowing that 1 100 seats are used doesn't tell you whose they are. The Business Units screen answers that, and turns usage into internal cost.
Membership comes from one CSV that you own — workspaces/<folder>/business-units.csv, two columns, email and unit. That file is the single source of truth: no in-app import, no hidden state to drift out of step with your own HR or finance list. The header is optional, and comma, semicolon and tab separators are detected automatically. Edit the file externally, then click Refresh from CSV. The status strip reports how many rows were read, how many units they describe, how many matched a real user, and how many emails matched nobody.
Only full internal-seat licences are considered (Salesforce, Platform, Platform Login); community logins are out of scope.
The screen is a tree you expand:
A row per business unit — its members, and the licence volume you credit to it.
Per mapped product, inside a unit: Credited (the quantity you allocate to the unit), Backcharge (the internal cost you cross-charge for it), Used, Allocated, and Not yet — the members drawing the product beyond what the unit has been credited.
Expand further to the actual people, drilled org › licence type › profile › user. Every seat is traceable to a name.
Unmapped licences collects members holding a licence that no mapped product covers — your to-do list for mapping.
No business unit collects full-licence users whose email is absent from the CSV. Members in units plus this row always reconciles to the total number of full licences, so nobody quietly disappears.
If your CSV renames or drops a unit, the credit you had allocated to it is flagged rather than lost: Remap it onto a current unit, or remove it.
A unit's credit is a quota, not a fact: it is compared against what the unit really draws. That comparison — credited versus used, with a backcharge attached — is what makes an internal chargeback defensible.
Shelfware, named. Contracted, provisioned and used side by side, per product and per org.
Every Org ID identified, and linked to its analysis where you have one.
Every seat attributed to a business unit, down to the user, with the cost you cross-charge for it.
A renewal conversation backed by measurements instead of assumptions.
Link the orgs this contract covers, in Contract settings — mapping and business units depend on it.
Refresh the licensing analysis of those orgs: provisioned, used and the user-level drill all come from the latest analysis.
Name your orgs in the Orgs drawer, so every screen reads in your own vocabulary rather than in Org IDs.
Keep the CSV current. It is the one input the app can't derive for you — and the one that decides who pays.