Reconciling a day

Your notifications are the fast path; the portal’s inflow list is the authoritative one. Reconcile against the list, not against what reached your endpoint, and the day you had an outage looks the same as any other.

What a day is

Inflow windows in the portal are cut on Africa/Lagos calendar days, from midnight to midnight, not on UTC. A from date is inclusive and a to date is inclusive on screen (the bank’s query treats it as exclusive at the next midnight). The portal reaches back six months; for older records ask the bank. Webhook timestamps are UTC instants and the callback’s date is Lagos local time, so convert before comparing a notification’s time to a day boundary.

Pulling the day

1. On Inflows, pick the band. The list is per band; an organisation with several bands reconciles each.

2. Set the window to the day. Leave the status and notification filters open so you see everything, including reversals and payments you were not told about.

3. Read the summary strip: total count, total amount, distinct numbers paid, how many were notified, and how many were not notified. “Not notified” counts payments that were owed a notification and did not get one; it ignores payments on which nothing was owed.

4. Export. CSV or XLSX, up to 100,000 rows in one file; narrow the dates if the band is busier than that. Columns: Received, Virtual account, Account name, Amount, Sender, Sender account, Sender bank, Narration, Reference, Session ID, Notified, Notified at, Attempts, Response, Error.

Matching

Match each exported row to your own record of the number and the notification you received.

Your side	Export column	Callback field (REMOTE)	Webhook field (LOCAL)
The number you issued	Virtual account	accountNumber	virtualAccountNumber
Your order or invoice id	Account name, or your own map of number to external_ref	not carried	externalRef
The transfer	Session ID	reference	nipSessionId
The bank’s booking	Reference	not carried	reference
What the payer sent	Amount (gross)	amount (gross)	grossAmount; amount is net

The session id is the key that survives every system: the payer’s bank, NIBSS, the bank and you all hold it. Match on it first. The transfer reference is the bank’s own booking id and is what a bank operator will look up.

Gross versus net

The export and the callback carry the gross amount. The webhook’s top-level amount is the net credited after the band fee, with grossAmount and feeAmount beside it. If your band is priced, reconcile on gross and account for the fee separately, or your totals will disagree by exactly the fees.

Three outcomes per row:

• Matched, notified. Nothing to do.
• Matched, not notified (Notified column FAILED, SKIPPED or PENDING past its retries). The money is in your account; your system does not know. Apply it from the export, and on a REMOTE band use Resend on the payment to put your endpoint right.
• Not in your records at all. Someone paid a number you issued and you never recorded issuing it, or paid a number on a REMOTE band you never handed out. Fulfil or refund from the sender details in the row, and look at how the number got out.

Then the other direction: every notification you received that is absent from the export. On a day with no reversals there should be none. A notification for a session id the portal does not show is worth a call to the bank, with the body you received.

Reversals and late changes

A credit can be reversed by the sending bank after you have fulfilled against it. The row’s status becomes REVERSED and the net is debited from the account that received it. On a LOCAL band you receive transaction.reversed; on a REMOTE band you receive nothing, so include REVERSED rows in the day’s run, and re-run yesterday as well as today.

Settlement between the bank and NIBSS happens the next business day and is not shown in the portal. It does not change your account. If the bank ever needs to take a credit back because NIBSS did not settle it, that is handled with you directly, not by an automatic debit.

Raising a payment with the bank

A query the bank can answer in one look carries:

• the session id (reference in the callback, nipSessionId in the webhook, Session ID in the export);
• the virtual account number and the day;
• the amount the payer says they sent;
• the sender’s account number and bank, if the payer gave them to you;
• your external_ref for the number;
• what you saw: no notification, a notification with a different amount, or a credit you cannot find on the Inflows page.

If the payer has a NIP receipt from their own bank, the session id on it is the single most useful item. A payment the bank refused at name enquiry or at credit never appears on Inflows; the payer’s bank holds the decline reason, and Failure modes lists what each one means.

In the portal

Inflows is the reconciliation surface: band, Lagos-day window, status and notification filters, search by number or reference, summary strip, CSV and XLSX export, and the per-payment detail with the notification outcome and Resend.