Provider and ledger disagree
A provider confirms money went back to the customer, but the ledger has no related adjustment. The original sale stays uncorrected in the records finance uses to reconcile each period.
Payments
A provider refund completes, but accounting still shows the original sale with no adjustment. Partial refunds may arrive with the wrong amount. We trace refund references, apply your finance team's approved posting rules and reconcile reviewed gaps in the ledger.
Discuss this problemYour finance team first defines what a completed refund should create in the books, including tax and partial amounts. We follow a redacted provider reference through the connector until the ledger accepts it. Rejected entries and missing links to the original sale help explain the backlog. We compare existing manual corrections before recovering past refunds, so the same refund isn't posted again. You get linked records of each transfer and a practical way to review refunds the ledger rejects.
A provider confirms money went back to the customer, but the ledger has no related adjustment. The original sale stays uncorrected in the records finance uses to reconcile each period.
A partial refund creates a full reversal or another wrong amount in the books. The entry doesn't describe the money really returned against the customer's original purchase.
Failed refund transfers go unnoticed until finance closes the period. By then, staff face a catch-up job over past records, not a small exception reviewed soon after it was rejected.
We trace the completed refund reference from the provider through the connector's results. What the ledger did next shows whether it rejected the entry, never got it, or posted it under an unexpected relationship.
We compare amount and tax mappings with the treatment finance approved. A partial refund needs its own evidence, not a rule that simply reverses every value from the original sale.
We review rejected transfers for bad references, closed periods and the ledger's own checks. The reasons show which records need corrected data and which need an accountant's decision before recovery.
We set up the approved adjustment mapping and keep the original sale and refund references. Completed, requested and failed refunds keep their separate meanings as they post downstream.
We show ledger rejections to a named finance owner, with safe supporting references. Staff can work out why a refund is missing without searching through unrelated customer or payment data.
We recover a reviewed period of missing refunds after comparing existing ledger adjustments. Manual corrections are linked or excluded, and each accepted recovery is kept as evidence for final reconciliation.
No, your accountant or finance owner approves how refunds affect the ledger, including dates and tax treatment. We set up that decision and flag exceptions. The transfer should keep the approved meaning, and not bring in a new accounting policy through its mappings.
We check existing adjustments before recovery. A manually corrected refund must be linked or excluded, so the connector doesn't post another adjustment. Finance reviews any entry whose ledger reference doesn't clearly point to the original provider refund.
It depends. Requested and completed refunds can need different reporting treatment. We agree which provider statuses belong in the ledger and how failed requests are shown. A message alone should not make a refund look complete in the books, unless its evidence supports that approved status.
Name your payment and accounting systems, then share one redacted completed refund and the expected ledger treatment. Keep safe payment references and amounts, so we can compare the transfer with finance's records.
Tell us about your project and we'll get back to you within 24 hours.