What finance needs from a prepaid integration
Give finance a way to follow each order from the approved request to the line on the supplier statement. Agree on the references, amounts and statuses before you build. Otherwise someone will have to piece them together at month-end.
| Record field | Why finance needs it |
|---|---|
| Business reference | Match to request or campaign |
| Supplier reference | Trace supplier-side outcome |
| Amount and currency | Reconcile value |
| Status and timestamps | Identify pending or completed items |
| Cost centre | Allocate expense |
By Freepaid · Published
Define the transaction fields finance needs
Suppose a department approves 25 rewards at R40 each. The approved face value is 25 × R40 = R1,000. Finance still needs actual supplier charges and final order evidence before treating R1,000 as the settled cost.
Agree which fields your app must keep, including the internal and supplier references, product, quantity, unit value, currency, cost centre, requester, approver, submission time and status. Show finance how pending, rejected, reversed and unknown outcomes appear. Ask them to approve how each maps to the ledger and who follows up if the records differ.
Agree the record before writing code
Put one example order in front of finance and operations. Include its request ID, supplier reference, product ID, quantity, face value, any price or fee fields, currency, cost centre, approver, timestamps and status. Ask which record should take precedence if the reports disagree.
On that 25 × R40 request, keep the approved count and R1,000 face value. Show the submitted, completed and failed orders separately so finance can see how much of the batch went through.
Avoid storing more recipient information than the fulfilment and audit process needs. Decide where protected data lives, who can view it and how long it is retained. Finance should identify how to handle rounding, reversals and invoice timing before implementation.
Define the fields in the finance export
Ask finance to test a sample ledger row from request through statement. Agree which record identifies the business purpose, which one identifies the supplier transaction and how partial completion appears. Keep currency and amount definitions explicit, including whether the field is face value, fee or total payable.
Example: an approved request for 10 items at R25 has R250 face value. If only 9 complete, finance should see the completed value R225 and one exception, not a settled R250 delivery. Supplier charges may be invoiced separately, so use the invoice as evidence for the actual payable amount.
Before launch, ask finance to match the order to a cost centre, name the requester and approver, find the supplier record and explain any reversal or variance. If they can’t tell which orders are pending and which completed, fix the export and try again.
Reconcile one incomplete batch before sign-off
Have finance match a sample approval to the supplier statement and then to the ledger. Look for the same transaction in both the application and the statement before posting anything twice. Agree how to show part of a batch and who investigates a mismatch. If settlement relies on the statement, include it in the evidence even when the API reports success.