Where Did the Credits Go? Reconcile Outbound Usage Before Buying More
TL;DR: Do not buy more outbound credits until every consumed unit can be reconciled to a workflow action, provider, reporting period, and usable result. Separate included seat allowances, shared pools, top-ups, resets, retries, and failed outputs. Then calculate cost per approved outcome, not cost per nominal credit.
How do I reconcile outbound data and AI credit usage with the workflows that consumed it?
Build a consumption ledger that joins billing terms to action-level activity. The ledger should answer five questions for every period: what action ran, which workflow initiated it, which provider or model fulfilled it, how many billable units were charged, and what usable result was produced. A balance alone cannot answer those questions. It shows remaining capacity, not whether the capacity created usable records or whether a configuration mistake consumed it.
Start with the current plan and contract, then verify the usage screen and documented credit rules. Unify’s credit documentation states that different activities consume credits and that consumption can vary by feature. Current public pricing also distinguishes included credits and plan structures. Because rates, allowances, and contracts can change, store the observed rate or charge from the period being reconciled rather than relying on an old planning sheet.
| Field | Purpose | Example value type | Owner |
|---|---|---|---|
| Reporting period | Align usage with allowance, reset, and invoice | Start and end timestamps | Finance or RevOps |
| Workflow and version | Identify the configuration that initiated work | Play, list, sequence, or agent ID | Workflow owner |
| Action type | Explain what consumed units | Email enrichment, phone enrichment, research, reveal | Operations |
| Provider or model | Separate fulfillment paths and rates | Named source or model version | Data owner |
| Billed units | Reconcile balance movement | Observed credits or invoice units | Finance |
| Usable result | Measure accepted output | Verified field, approved answer, eligible record | Business owner |
Separate every credit pool before doing the math
Do not combine included seat allowances, workspace pools, purchased top-ups, promotional balances, and contract-specific allocations into one undifferentiated number. Record the opening balance, additions, expirations or resets, transfers if the product permits them, usage, adjustments, and closing balance for each pool. If the platform does not expose every movement, document the gap and ask support rather than forcing the numbers to reconcile through an invented adjustment.
Allocation rules matter. A workflow might draw from a seat allowance first and then a shared pool, or it might use a workspace-level balance. Top-ups may follow different expiration or billing rules. Reconciliation should mirror the product’s actual order of operations for the period. The goal is not to make the spreadsheet equal the invoice at any cost. The goal is to explain every material difference with evidence.
- Capture the exact plan, contract period, and workspace in scope
- List every credit pool with its opening balance and reset rule
- Export or record action-level usage for the same time window
- Map retries, fallbacks, and multi-provider waterfalls to the originating workflow
- Keep an explicit unresolved-difference line until the cause is verified
Trace consumption from workflow to usable output
One business request can create several billable actions. A request to find prospects may search records, enrich an email, enrich a phone number, run an agent question, and evaluate a signal. A waterfall can query more than one provider before producing a single accepted field. A retry can consume work without creating a new record. The ledger must preserve this one-to-many relationship instead of assigning the entire charge to “prospecting.”
Define usability before calculating efficiency. For an email, usability might require uniqueness, a permitted send status, and the fields needed for routing. For an agent answer, it might require a supported answer, the expected format, and a pass against a review rubric. For a revealed company, it might require ICP eligibility and a resolvable account. Different outputs need different acceptance tests, so do not use one generic success flag.
| Workflow request | Possible billed actions | Usable-result test | Common leakage |
|---|---|---|---|
| Build a contact list | Search, person enrichment, email, phone | Unique eligible person with required verified fields | Over-broad persona or excessive contacts per account |
| Research an account | Agent questions, web or data retrieval | Required fields answered with acceptable evidence | Duplicate questions or unnecessary depth |
| Activate a signal | Reveal, signal lookup, enrichment, qualification | Eligible account or person enters the correct path | Low-value trigger or missing suppression |
| Retry a failed step | Repeated provider or model call | New usable result not already present | Automatic retries without stop condition |
| Reprocess imported data | Normalization and enrichment | Net-new accepted fields | Duplicates and already-complete records |
Calculate unit economics with the right denominator
Use billed units or actual cost as the numerator and accepted outcomes as the denominator. Cost per lookup can be useful for procurement, but it does not show operational value. Cost per usable email, qualified account, approved agent answer, or eligible signal is more informative. Keep the raw counts beside the rate so reviewers can see whether the metric improved because quality rose or because acceptance criteria changed.
For email verification specifically, Email Verification on a Budget explains how to count unique deliverable addresses and preserve result codes. For broader stack planning, How Much Does It Cost to Start Outbound? separates platform, data, sending, and operating costs.
| Metric | Formula | What it reveals | Caution |
|---|---|---|---|
| Credit variance | Recorded pool movement minus action ledger | Missing events, adjustments, or timing differences | Do not hide with manual plug |
| Credits per usable result | Billed units divided by accepted outputs | Workflow efficiency | Acceptance rules must stay consistent |
| Retry share | Units used by retries divided by total units | Failure recovery cost | Some retries are legitimate |
| Duplicate consumption share | Units tied to already-known outputs divided by total | Deduplication gap | Requires stable record keys |
| Unused allowance | Expired or reset units divided by allocated units | Capacity planning mismatch | Pooling rules can change interpretation |
Investigate variance in a disciplined order
First check time zones and period boundaries. A workflow that begins before midnight and finishes after it can split usage across reports. Next check workspace and seat filters. Then inspect retries, fallbacks, deleted workflows, duplicated imports, and vendor-specific billing units. Compare the usage event timestamp with the invoice or balance-posting timestamp. Only after these checks should you escalate a suspected billing discrepancy.
Keep evidence for each adjustment: screenshot or export reference, support case, contract clause, or product documentation title. Do not overwrite original values when a discrepancy is resolved. Add an adjustment row with the reason and approver. That preserves an audit trail and prevents the same unexplained variance from returning next month.
Reduce consumption before increasing capacity
- Limit prospects per account to the number the buying motion can use
- Run qualification before expensive enrichment when the inputs support it
- Deduplicate stable record keys before any provider call
- Stop waterfalls when an accepted field is found
- Cap retries and route persistent failures to review
- Remove unused agent questions and overlapping signal checks
- Alert when a workflow crosses its expected daily or per-record usage band
Use alerts as investigation prompts, not proof of waste. A product launch or new territory can legitimately change usage. Compare the increase with volume, workflow version, and usable outputs. If both consumption and approved outcomes rise proportionally, the workflow may be working as intended. If consumption rises while accepted results remain flat, inspect the action mix before purchasing more credits.
Turn the ledger into a monthly operating review
Review consumption by workflow owner, action type, segment, and result state. Ask which increase was planned, which was caused by more volume, which came from a version change, and which produced no accepted output. Assign one owner to every material variance and a due date for resolution. Repeated unexplained usage should block capacity increases until the event path is understood.
Keep procurement and workflow decisions connected. Finance may care about committed capacity and invoice timing, while RevOps cares about action-level waste and usable outcomes. A shared ledger lets both teams use their preferred view without maintaining conflicting totals. Document the rate source and reporting window on every decision memo so a later plan change does not make the historical calculation appear inconsistent.
Frequently asked questions
Should credits be reconciled to invoices or product usage?
Both. The invoice or plan explains purchased capacity, while the usage ledger explains which actions consumed it and what outcomes resulted.
What should happen when the ledger does not match the balance?
Keep the difference explicit, check period, workspace, pool, retry, and adjustment rules, then escalate with evidence. Do not invent a balancing entry.
When is it reasonable to buy more credits?
After current consumption is explainable, the workflow produces accepted outcomes at a known rate, and forecast demand exceeds verified remaining capacity.
