On this page
A completed reward should be traceable across the records held by the merchant, the platform, and the issuing provider. Those records may use different identifiers and describe different events. A bank transfer proves something different from an award approval or a confirmed card load.
A three-way reconciliation identifies the source of truth for each event and preserves the relationships between them. It does not require pretending that all organizations use the same identifier or that a particular customer’s purchase dollars can be followed physically into one reward card.
Choose the source of truth for each event
Start with one award and its original purchase relationship. Identify the merchant record supporting program funding, the platform or operational record supporting the award decision, and the provider record confirming issuance or load. Each source should answer the question it is authoritative for.
For a hypothetical case, order O-3601 supports a $30 award, AW-2201. The merchant separately funds the program with $200 under transfer BT-81. The provider confirms the funding credit and a $30 load for AW-2201. Other awards may also use the funding pool; the reconciliation is a record relationship, not a claim about segregated ownership of particular dollars.
RebateCardX’s reporting capability page provides context for discussing program records. The exact exports, reference mappings, and provider confirmations must be established for the actual program. The worksheet below uses fictional records.
| Event | Authoritative source for this example | Reference | Amount | Relationship to the award |
|---|---|---|---|---|
| Qualifying purchase | Merchant order and eligibility evidence | O-3601 / QR-81 | Purchase amount recorded separately | Establishes the commercial basis |
| Funding sent | Merchant bank record | BT-81 | $200 | Supports the program funding instruction |
| Funding received | Provider funding record | FC-81 | $200 | Confirms receipt corresponding to BT-81 |
| Award approved | Authorized award record | AW-2201 / AP-81 | $30 | Defines the approved reward value |
| Load confirmed | Provider issuance record | IC-2201 / LD-81 | $30 | Confirms the value action for AW-2201 |
| Remaining funding in simplified statement | Provider funding statement | ST-81 | $170 | Reconciles $200 credit less $30 load in this isolated example |
The last row assumes no other movements in the simplified statement. In a real pooled program, every additional movement must be included before using the balance as a cross-check.
Join the purchase, award and funding references
The join should be explicit. O-3601 maps to AW-2201 through the approved eligibility record. AW-2201 maps to IC-2201 through the provider handoff and outcome. BT-81 maps to FC-81 through the funding instruction and provider acknowledgment. The funding statement then records the load movement with its own reference.
Do not join records only because their amounts match. Two awards can both be $30, and several transfers can be $200. Amounts are useful checks after the relationship is established, not unique identifiers that prove which events belong together.
Also compare currency, program, and recipient reference where relevant. A $30 USD load for another program does not reconcile AW-2201 merely because the numeric value matches. A correct amount attached to the wrong recipient is a substantive exception, not a successful reconciliation.
Preserve the difference between requested and confirmed value. An award record may show an intended $30 request while the provider has not returned a load outcome. In that situation, the platform side is complete as an instruction, but the provider side remains unresolved. Do not fill the confirmation column from the requested amount.
The worksheet should explain how identifiers were matched if no common reference exists. An approved reconciliation mapping can be valid, but it must be reproducible. A reviewer’s memory that “this was probably the transfer for that batch” is not a durable relationship.
Investigate missing or contradictory records
Suppose the provider confirms a $30 load but the award record remains pending. The reconciliation should identify the existing issued outcome and route the state correction. It should not submit another $30 reward to make the local record catch up.
A filled completion note could read: “AW-2201 is supported by purchase review QR-81 and approval AP-81. Provider load LD-81 confirms $30 under IC-2201 and maps to the original award handoff. Funding credit FC-81 matches merchant transfer BT-81. The simplified statement reconciles $200 funding less $30 loaded to $170 remaining. No unmatched movement remains in this reviewed scope.”
A difficult case is a provider load amount differing from the approved award. Preserve both values and the original request evidence. The discrepancy may involve a wrong reference, an adjustment, or an actual processing issue. Do not edit the approved amount to match the provider record without an authorized explanation.
Another case is funding arriving in several credits while the merchant sent one transfer. The funding relationship may still reconcile through a documented component mapping. Keep the component references and their total rather than treating each smaller credit as a separate missing transfer.
An unmatched purchase record also deserves attention. The existence of an issued card does not establish that the underlying award had a valid commercial basis. Trace the approval and purchase relationship rather than limiting reconciliation to whether two monetary numbers agree.
The finished worksheet establishes a source for each event and a reproducible mapping between them. It shows that the intended award, the actual provider value action, and the program funding records refer to the same reviewed business case without collapsing their different meanings.
Discuss which references are available for reconciling your program across participating parties.
Source references
This guide is general information, not financial, legal, tax or regulatory advice. Eligibility, card availability, permitted use and responsibilities depend on the applicable offer and card terms.