Transaction reconciliation in Hi Energy AI: statuses, corrections, and monthly close

Why reconciliation is hard in affiliate

Every network invents its own transaction vocabulary: locked, available, reversed, declined, State=REVERSED next to a stale Status=Approved, positive clawbacks, negative clawbacks. Finance and AMs still need one answer: what is pending, what is approved, what is paid, and what was corrected for the month you are closing.

Hi Energy AI reconciles that mess into four normalized lifecycle statuses and reporting surfaces built for monthly payout review.

The four statuses that matter

Cross-network rule of thumb: a negative commission_amount always maps to corrected, even if the raw status token still says something friendlier. When raw fields conflict, the mapper prefers the more severe outcome (for example Impact State=REVERSED over a stale approved status).

Mappings live in network status config and are applied as transactions sync and upsert. Historical rows can be backfilled when mapping rules change.

Where to reconcile in the product

Transaction list + month window

A calendar month is what a network statement covers and what a payout is reconciled against. On transactions, pick a named month (for example 2026-07) instead of hand-typing the first and last day. The list and its Google Sheets export share that month parameter so the spreadsheet matches the month you were looking at.

Filter by normalized status (pending, approved, paid, corrected) the same way the Transactions API does.

Transaction status report

Open Transaction status report for daily counts and KPIs by the four statuses, with network breakdowns and publisher filters (where your role allows).

• Corrected KPI cards describe commissions corrected in the selected period
• Click through to the network status mapping modal to see how each network’s raw tokens land in pending / approved / paid / corrected
• Corrected sales and commission totals use absolute values so networks that sign corrections differently still sum to a meaningful “how much was corrected” number

Age and network views

Use the transaction age and network reports alongside status breakdown when you need unpaid aging or network-level mix — useful when a close question is “how old is pending?” or “which network is driving corrections?”

A practical monthly close checklist

1. Pick the statement month on transactions (not a fuzzy trailing 30 days unless that is what the network invoice uses).
2. Export or filter paid for the month and compare to the network payout.
3. Review corrected with absolute KPIs on the status report — dig into advertisers or networks with large correction volume.
4. Spot-check pending that is aging longer than your network’s lock window via the age report.
5. When a raw status looks wrong, open the status mapping modal before assuming the feed is broken — many “bugs” are vocabulary differences already normalized.

API, GraphQL, and agents

• REST: GET /api/v1/transactions?status=corrected (repeat status for multiple values)
• GraphQL: filter by normalized status; status timestamps expose pendingAt / approvedAt / paidAt / correctedAt when the network provides them
• MCP: search_transactions / get_transaction with the same permission model as the app

Bottom line

Transaction reconciliation in Hi Energy is not a separate product silo — it is normalized status + month-scoped lists + status/age/network reports. Map every network into pending / approved / paid / corrected, close on calendar months, and treat corrected as a first-class bucket with absolute KPIs so clawbacks do not disappear in the math.