Skill · Finance and Operations

Revenue Reconciliation

Check revenue freshness, completeness, duplicates and source totals before releasing a report.

At a glance

Revenue Reconciliation is an AI skill for finance & operations teams that you can use in Claude Code, Codex, or type.com.

Updated

What it does

  • Reconcile to independent source reports at the same scope.
  • Explain differences and late refunds without balancing plugs.
  • Return READY, PROVISIONAL or HOLD with evidence and next actions.

Before you start

  • Revenue Definitions and approved tolerances.
  • A report snapshot, event ledger, extraction manifest and independent source controls.

See an example

Example output from a sample run. Company names and figures are sample data.

Revenue release check: Northwind Goods, Tue 16 Sep (USD)

Status: HOLD. Shopify and Amazon tie out. Wholesale is 100 short of its control total, and its feed freshness can't be confirmed.

CheckExpectedObservedResult
Feed freshnessAll feeds current through 23:59 cutoffWholesale watermark missingUnverified
Event uniquenessUnique event keys; partial refunds keptNo conflicting duplicatesPass
Shopify tie-outControl 850Report 850 · residual 0Pass
Amazon tie-outControl 1,700Report 1,700 · residual 0Pass
Wholesale tie-outControl 2,800Report 2,700 · residual −100Hold

Subtotal so far: 5,250. Not publishable until wholesale is resolved.

Next actions

  • Data owner (Priya): confirm the wholesale feed is complete through cutoff.
  • Finance (Tom): trace the 100 difference to a missing invoice or credit note.
  • Re-run against the same snapshot once both are cleared.

Draft message for #revenue (not sent):

Today's revenue number is on hold. Wholesale data isn't confirmed fresh and is 100 below its control total. Priya and Tom are on it; next update after reconciliation.

How to use Revenue Reconciliation

  1. type.com: Choose Use Skill to add Revenue Reconciliation to your type.com workspace.
  2. Claude Code: Download the skill and extract it into ~/.claude/skills/revenue-reconciliation/ (or .claude/skills/revenue-reconciliation/ in a project). Then ask Claude to use Revenue Reconciliation.
  3. Codex: Download the skill and extract it into ~/.agents/skills/revenue-reconciliation/ (or .agents/skills/revenue-reconciliation/ in a repository). Then ask Codex to use Revenue Reconciliation.

AI agents can read this page as Markdown or fetch the raw SKILL.md.

Frequently asked questions

What is Revenue Reconciliation?

Revenue Reconciliation is an AI skill for finance & operations teams that you can use in Claude Code, Codex, or type.com.

What does Revenue Reconciliation do?

Check revenue freshness, completeness, duplicates and source totals before releasing a report.

What do I need to use Revenue Reconciliation?

Revenue Definitions and approved tolerances; A report snapshot, event ledger, extraction manifest and independent source controls.

Can I use Revenue Reconciliation in Claude Code or Codex?

Yes. Revenue Reconciliation is a standard Agent Skills folder with a SKILL.md file. Download it and extract it into ~/.claude/skills/ for Claude Code or ~/.agents/skills/ for Codex.

Who created Revenue Reconciliation?

The type.com team created Revenue Reconciliation. The type.com team reviews every skill before it is published in the Skills Library.

  • Budget PacerProject month-end spend from a trailing run rate across campaigns and clients, flag over- and under-delivery beyond a tolerance, and recommend per-campaign daily budgets that reconcile exactly to each client's committed total.
  • BFCM Cohort QualityFind out if last Black Friday's new customers were worth it: contribution, repeats and payback vs October and January buyers, by discount, source and product.
  • Holiday Support MacrosPrepare your support team for BFCM: forecast holiday tickets and staffing, find policy gaps and stale macros, and generate holiday macros built only from your written policies.
  • Holiday Shipping Cutoff CheckerFind the last day customers can order on each shipping service and still get it by the holiday, check every delivery promise against it, and plan the switch to expedited and e-gift cards.
  • BFCM Live PulseTurn hourly sales and ad spend into a BFCM status update with sales pacing, budget guardrails, checkout alerts, code-use anomalies and stock risk.
  • BFCM Offer & Discount Config QACheck your Shopify BFCM discounts against the offer plan before launch: stacking, sale windows, who gets each discount, code limits and free shipping, with test carts and a dated fix list.

AI for finance and operations teams: a practical guide

Browse the technical files
---
name: revenue-reconciliation
description: Validate a revenue report before publishing by checking source freshness, extraction completeness, duplicate events, independent control totals and late refunds. Use when sales numbers disagree, a feed may be stale, or a daily Slack revenue report needs a release decision.
---

# Revenue Reconciliation

## Shared definitions prerequisite

Read and apply the [Revenue Definitions skill](https://type.com/library/skills/revenue-definitions) before this workflow. If installed as sibling folders, read `../revenue-definitions/SKILL.md`; otherwise load the installed skill by name or obtain its published instructions. Reuse the business's existing approved definition file. If it is missing, establish it with Finance through that skill; never infer approval or overwrite another client's rules.

Independently validate a specified revenue report. Produce a **READY**, **PROVISIONAL** or **HOLD** decision with evidence and a draft message. This is sales-report reconciliation; bank/processor-to-GL reconciliation is a separate workflow.

## Establish the exact run

Load the approved revenue definition, report, event ledger, exclusion/duplicate log, calculation reference and extraction manifest. Record report/run ID, definition version, period, entity, channel/account/market scope, timezone, currency and as-of cutoff.

A report generated by another workflow is acceptable if it provides equivalent evidence. Revenue Reporting is an optional producer; accept equivalent report evidence without requiring that producer to be installed. Missing evidence remains an explicit failed or unverified check.

Use approved thresholds; never adopt arbitrary monetary tolerances, expected volumes or refund ages from examples. Record whether absolute/relative tolerances use AND or OR and whether they apply to raw differences or unexplained residuals. Calculate percentages against the absolute control total; when it is zero, use the approved absolute rule and display relative difference as N/A.

## Run the checks

1. **Freshness:** inspect both extract time and source data-through watermark for every required feed. Check load status and lag against its SLA. The newest sale timestamp alone cannot prove freshness; a quiet business can legitimately have no sales.
2. **Completeness:** verify all pages, accounts, markets, files/partitions and required time windows arrived. Confirm a complete closed day or label intraday coverage. Check count/sum controls and refund/update coverage for older orders. Validate empty channels against source evidence; zero sales are not inherently a failure.
3. **Uniqueness and joins:** validate event keys at their declared grain. Distinguish exact replays, legitimate multiple refunds, updates and conflicting duplicates. Inspect cross-channel mappings and orphan mirrors. Where source IDs are available, compare key sets in both directions; equal totals can conceal a missing and an extra order.
4. **Independent source tie-out:** retrieve the agreed native control report or a separately governed control. Two warehouse tables derived from the same flawed feed are not independent evidence. Match scope, date basis, timezone, status filters, currency and gross/net definitions before comparing. Do not force a match by excluding unexplained records.
5. **Bridge differences:** show control total, report total, raw difference, each evidence-backed adjustment and remaining unexplained residual. Typical explanations include timezone boundaries, excluded orders, duplicate mirrors, late updates/refunds, FX, rounding and different metric definitions. Distinguish a proved cause from a hypothesis. Never use a balancing plug or assumed refresh lag as an explanation.
6. **Refunds and restatements:** identify late refunds and changes to earlier reports. Apply the approved refund-date or original-sale rule, show affected periods and deltas, and flag closed-period approval requirements. An explained late refund is not automatically a blocker; an unprocessed or unexplained one may be.
7. **Arithmetic and policy:** recompute the gross-to-net bridge, FX conversion and channel sum; check tax/shipping/discount/refund components are counted once. Verify excluded orders and estimates are disclosed and the policy version is correct.

If controls are unavailable or only share the same lineage, state the limit. Do not claim independent reconciliation.

## Decide

- **READY:** required checks pass under approved rules; sources and scope are complete; residuals are within approved tolerance; known caveats are disclosed.
- **PROVISIONAL:** policy explicitly permits a named limitation, such as an intraday report or documented noncritical delay. Show affected scope, potential impact and owner. If no policy permits it, use HOLD.
- **HOLD:** required input/control is missing or stale, scope is incomplete, duplicate conflicts remain, required policy is unresolved, or an unexplained difference breaches tolerance.

Readiness is specific to this report snapshot and cutoff. Changed inputs require a new validation. A READY decision is not authorization to send a message.

## Deliver

Lead with status and period. Provide:

| Check/source | Expected | Observed | Raw difference | Explained adjustments | Residual | Status | Evidence | Owner / next action |
|---|---|---|---|---|---|---|---|---|

Include counts and amounts affected; separate observed errors from unknown exposure. List prior-report corrections and reference the exact run/calculation/version.

Draft a concise daily message:
- READY: approved net sales, channel breakdown, timezone/currency, data-through cutoff, definition version, reconciliation result and material caveats.
- PROVISIONAL: lead with PROVISIONAL and coverage; label any subtotal explicitly.
- HOLD: lead with what prevents publication, responsible owner and next check. Keep diagnostic figures in the evidence section so they cannot be mistaken for the final daily revenue number.

Do not post, edit past Slack messages, fix production records or change revenue policy. Pass the draft and decision to the separately authorized distribution workflow.

## Validate the gate

Use synthetic cases before relying on a new mapping: fresh extraction with stale underlying data → HOLD; legitimate zero-sales channel with complete controls → eligible for READY; equal totals but differing record IDs → investigate; unexplained breach → HOLD; explained late refund handled under approved policy → disclose and assess remaining checks. Test zero control totals and the exact approved AND/OR tolerance rule.