Finance and Operations
Revenue Reconciliation
Check revenue freshness, completeness, duplicates and source totals before releasing a report.
TypeWhat 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
Revenue release check
HOLD — synthetic example, USD. Report snapshot: illustrative daily run; definition approval and thresholds are assumed solely for this example.
| Check | Expected | Observed | Result |
|---|---|---|---|
| Feed freshness | All required feeds current through cutoff | Wholesale watermark unavailable | Unverified |
| Event uniqueness | Unique event keys; valid partial refunds retained | No conflicting duplicates in supplied ledger | Pass |
| Shopify tie-out | Control 850 | Report 850; residual 0 | Pass |
| Amazon tie-out | Control 1,700 | Report 1,700; residual 0 | Pass |
| Wholesale tie-out | Control 2,800 | Report 2,700; raw difference −100; no proved adjustment | Hold |
Diagnostic consolidated subtotal: 5,250; not a final publishable revenue number. The wholesale residual is −100 under report-minus-control convention; its cause is unknown.
Owner / next action: data owner verifies wholesale completeness; Finance investigates the 100 difference. Re-run against the same or a newly identified snapshot after resolving both.
Draft daily message: “Revenue report on hold: wholesale data freshness is unverified and source totals differ by 100. Owners are checking the feed and invoice/credit-note coverage. Next update follows reconciliation.” No message has been sent.
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.