ERP payment reconciliation — ending the CSV era of cash application

It replaces the CSV-based cash-application workflow most AR teams run today: download a settlement report from the gateway or bank, match each line to an invoice in the ERP, key the cash receipt into the ERP, then reconcile the deposit total at month-end against bank statements and gateway funding.

Payment Hub writes per-transaction cash receipts to the ERP in real time at the moment the customer pays, so cash application is already done by the time the batch lands at the bank. Settlement reports from the gateway match automatically against the already-posted receipts. What remains is a morning review of exceptions rather than three days of data entry.

Yes. Payment Hub tracks each transaction from customer-payment through gateway-settlement through bank-deposit, with the settlement batch ID on both sides so the gateway's funded batches match the bank's ACH / card deposits automatically.

When the bank deposit lands in the ERP's bank-reconciliation module, the underlying gateway-settled transactions are already applied to invoices — the deposit reconciles as a single bank line tied to a group of already-applied receipts. No matching spreadsheets; no "why doesn't Friday's batch total the same as Monday's deposit?" investigation.

When a transaction returns — ACH NSF (R01), account closed (R02), authorization revoked (R07), or a card chargeback — Payment Hub ingests the return code from the gateway in real time, writes a reversing entry to the ERP that re-opens the original invoice with the return reason attached, and routes the exception to your AR worklist.

The deposit reconciliation adjusts automatically; your GL cash account stays correct. Re-presentment of NSF returns (up to 2 retries within 180 days per NACHA rules) is scheduled automatically. Your team sees the exception, not the ledger surgery.

Payment Hub separates cash receipts from surcharges and processing fees in the ERP posting — so your GL sees the true revenue (invoice amount), the surcharge income (pass-through, if enabled), and the processing-fee expense (merchant cost) as three distinct lines.

Bank deposits typically arrive net of processing fees; Payment Hub reconciles the deposit against the gross receipts plus the known fee amount, so your controller never wonders why the deposit was $24 short of the receipt total. Fee expense posts to the correct GL expense account as configured during implementation.

Payment Hub is gateway-agnostic — if you run Worldpay for card, Adyen for international, USAePay for branch counters, and ACH through the bank, every transaction from every gateway flows through the same Payment Hub reconciliation layer to your ERP.

Settlement batches from each gateway match against the corresponding deposits from each funding source. The AR team sees one exception queue, one cash-application view, one set of reconciliation reports — regardless of which gateway processed the transaction.

Month-end cash application compresses from a multi-day project to a review. Because every customer payment posted to the ERP in real time on the day it happened, the cash-GL, AR aging, and bank-reconciliation balances are current as of the closing date without catch-up work.

What's left is reviewing the small set of exceptions (NSF returns, chargeback reserves, partial payments flagged for AR review). Most Clarity customers report month-end AR work dropping by 60–80%, freeing the controller and AR team for analysis rather than data entry.

Yes. Credit memo applications, refund transactions (to the original payment method), and short-pay adjustments all post as separate records in the ERP — not blended into cash receipts.

Credit memos close against the specific invoices they were applied to; refunds reference the original payment token and the original cash receipt; short-pays leave the unpaid balance open with a reason code. The ERP reconciliation stays exact because each adjustment has its own audit-traceable record.

Yes — this is one of the main benefits of real-time reconciliation. Every Payment Hub transaction record links: the customer's authorization (timestamp, IP, method), the gateway reference ID, the settlement batch ID, the bank deposit reference, the ERP cash-receipt ID, the invoice ID, and the GL account posted to.

For external audits (financial, tax, grant, SOX, etc.), the audit trail is a single query or export from Payment Hub rather than a cross-system reconciliation project.

Rare but it happens — a transaction fails to fund, a batch splits unexpectedly, a chargeback reserve gets withheld. Payment Hub monitors every settlement batch for mismatches against the per-transaction receipts it's already posted. When a mismatch is detected, the batch surfaces in the reconciliation exception queue with a diff showing exactly which transactions are unaccounted-for, so your controller can resolve it the same morning rather than discovering it three weeks later.

Refund records post in the period they occur, with a reference to the original payment and the original cash-receipt entry. Your ERP's revenue-recognition and period-close rules handle the accounting treatment based on the refund-date posting — Payment Hub supplies the correct data; the ERP handles the accounting logic.

Yes. Your ERP's bank-reconciliation module is still where bank statements are matched to GL entries. Payment Hub makes that step easier by ensuring the contributing cash-receipt entries are already posted with the correct settlement batch reference by the time the bank deposit appears. Your bank-reconciliation clerk still does the final sign-off; the per-deposit matching is a one-click confirmation rather than a spreadsheet exercise.

A typical Payment Hub + ERP go-live takes 48 hours once Clarity receives ERP sandbox credentials and gateway API credentials. GL account mapping (cash, AR, credit-memo liability, chargeback reserve, surcharge income, processing-fee expense) is configured during implementation based on your existing chart of accounts.

No ERP schema changes; no custom GL accounts required (unless you want to add them); no disruption to month-end close cycles already in flight. Your existing gateway(s) stay intact.