A digital voucher campaign is only finished when the approved recipients, wallet spend, SIMcloud orders, completed vouchers and delivery records agree. Reconciliation is what separates a controlled reward programme from a folder of exported codes.
This guide applies to voucher orders created individually, through bulk CSV or through the VAS API.
Define the records you will reconcile
Use four layers:
| Layer | Source | Key fields |
|---|---|---|
| Approval | HR, marketing, customer service or finance | Recipient reference, product, value, approver and budget. |
| Fulfilment | Portal, CSV batch or API | SIMcloud batch/order ID, transaction ID, reference, product and amount. |
| Financial result | SIMcloud wallet and billing status | Total billed amount and final billing state. |
| Delivery | Approved distribution channel | Recipient reference, delivery time and confirmation. |
The unique internal reference joins these layers. Names alone are poor reconciliation keys because they can repeat or change.
Separate reporting from voucher-code access
A reconciliation report normally does not need the voucher code. Codes are spendable value and should stay in the narrow fulfilment or delivery path.
- Exclude voucher codes from general CSV exports.
- Do not send codes to analytics or application logs.
- Restrict access to completed voucher details.
- Use order ID, transaction ID and internal reference for investigation.
- Record delivery confirmation without repeating the code.
Classify every order
- Export or retrieve every order created for the campaign window.
- Join it to the approved list using the internal reference.
- Flag approvals with no order.
- Flag orders with no matching approval.
- Group orders into pending, successful and failed processing states.
- Compare billing state with processing state.
- Compare successful orders with delivery records.
- Investigate duplicate references or multiple orders for one approval.
Do not force totals to match by deleting inconvenient rows. Preserve failed, pending and duplicate records and document how each was resolved.
Reconcile the campaign totals
At minimum, calculate:
- Number and value approved.
- Number and value submitted.
- Number and value successful.
- Number and value pending.
- Number and value failed.
- Number and value delivered.
- Unmatched approval and order counts.
Explain each difference. An approved row may have no order because the product became unavailable. A submitted order may remain pending. A successful voucher may still be awaiting delivery. Those are different operational problems and should not be collapsed into one “not complete” count.
Resolve exceptions safely
| Exception | Investigation | Resolution |
|---|---|---|
| Approved but not ordered | Check availability, validation and operator notes. | Fulfil after approval remains valid or return for a new decision. |
| Order without approval | Identify creator, source and reference. | Escalate under the organisation’s financial controls. |
| Pending too long | Open the existing order and retain its identifiers. | Contact support without creating a duplicate. |
| Failed order | Record the failure reason and billing result. | Retry only under the approved process and with a new traceable reference if required. |
| Successful but not delivered | Check the controlled delivery queue. | Deliver privately and record confirmation. |
| Possible duplicate | Compare recipient reference, product, value and timestamps. | Do not issue both codes until the owner resolves the exception. |
Build reconciliation into an API integration
For VAS API orders, store the local campaign ID, internal recipient reference, requested product and value before calling SIMcloud. After a successful POST, persist the returned order_id and transaction_id in the same local record.
Polling should update processing and billing states without overwriting the original request. Store timestamps and failure reasons. Keep completed voucher codes encrypted or in a purpose-built secret-delivery store, not in general request logs.
Reconciliation starts at design time. If the application discards SIMcloud identifiers or reuses vague references, a later report cannot reliably reconstruct what happened.
Close and retain the campaign
Close the campaign only after all exceptions have an owner and documented outcome. Retain the approval, reconciliation summary and non-secret order evidence according to the organisation’s record-retention policy. Remove temporary working files containing unnecessary personal information.
Frequently asked questions
Should a voucher reconciliation contain the codes?
Usually no. Use order identifiers, references, products, values and statuses for reporting.
What is the best matching key?
A unique internal reference created before fulfilment and carried through the SIMcloud order.
Is a successful order the same as delivered?
No. Successful means the voucher was issued; delivery confirms that it was sent to the intended recipient.
What should we do with a long-pending order?
Investigate the existing order using its SIMcloud identifiers. Do not create another order merely to clear the report.
Can API orders be reconciled automatically?
Yes, if the integration persists local and SIMcloud identifiers, polls final status and records delivery separately.