WooCommerce and Acumatica refund reconciliation starts with a four-way match: the refund on the WooCommerce order, the payment provider’s record of money returned, the corresponding credit or refund in Acumatica ERP, and the payout or bank movement that settles it. Track each partial refund separately, link it to the original order and payment, and reconcile the stock movement on its own timeline. A WooCommerce manual refund records the decision in the store; it does not send money back. A partial refund can also exist without the order changing to Refunded. WooCommerce refund documentation
This guide shows ecommerce teams, controllers, warehouse leads, and integration owners how to build the match, handle exceptions, and prove that the accounting period is ready to close. It includes an illustrative two-refund order, a net payout that crosses month-end, and acceptance tests for the deployed connector and gateway.
What a reconciled refund proves
A refund is reconciled when a reviewer can follow the evidence from the customer’s order to the accounting entry and the settlement. The evidence should show what the merchant agreed to refund, whether money was actually returned or an authorization was released, how the adjustment was posted, and where the money appears in the processor’s balance or the bank. If an item came back, the reviewer should also be able to see how the warehouse handled it.
The four records answer different questions:
- WooCommerce order and refund: Which order, lines, quantities, tax, shipping, and amounts did the store record? Keep the original order ID and each refund ID, even when the storefront order number looks different.
- Payment provider: Which captured payment did the provider adjust? Keep the original charge reference, the refund or void reference, the amount and currency, and the provider’s status.
- Acumatica ERP: Which company, branch, customer, sales document, credit, refund, and inventory records reflect the event? Record the document type and number, the application or release state, and the financial period.
- Processor payout and bank: Which movement affected the processor balance, which payout or debit included it, and when did the bank record the transfer? Keep the payout or debit reference even when the bank entry represents many orders.
For an offline bank refund, the bank transfer evidence can cover both the payment and settlement questions. For a cancelled order with no captured payment, there may be neither a customer refund nor a payout movement to match. Record why a leg is inapplicable instead of forcing every case to create the same documents. Separate evidence requirements let you close uncomplicated cases promptly and isolate cases that need investigation.
Map the refund trigger before creating an ERP record
Start with the event that actually happened. A request, an approval, a cancellation, a gateway refund, a chargeback, and a warehouse receipt can all refer to the same order while representing different actions. Translate each event into the specific next step in the store, the ERP, and the payment workflow. Use the same decision rules whether a clerk or an integration receives the event first.
An order cancelled before a card payment was captured should route to an authorization check and an order fulfilment check. If the payment was captured, the team must determine whether funds were returned. Clicking a WooCommerce order status such as Cancelled or Refunded does not itself refund the customer. A customer service note can explain the decision, but the provider’s record proves the cash outcome. WooCommerce refund documentation
A returned parcel should route first to receipt and inspection. A price concession or a shipping refund can create a financial adjustment without an item returning. A dispute raised by a bank belongs in the dispute workflow; correlate it to earlier refunds before anyone issues another credit. When the trigger is unclear, keep the case open with the order and transaction references rather than guessing a financial document type.
Consider a store that refunds shipping because a delivery was late. The customer keeps the product, the gateway returns the approved shipping amount, and Acumatica records the approved adjustment against the original sale. The warehouse has no receipt to post. The same order might later have a genuine merchandise return, which needs its own event ID, its own amount, and its own warehouse disposition.
Know what automatic and manual refunds mean in WooCommerce
WooCommerce supports automatic refunds for compatible payment gateways and manual refunds when funds are returned outside the store. Automatic processing uses the supported payment method; the gateway’s response and order notes provide evidence of what happened. For manual refunds, a staff member still needs to complete the actual payment in the gateway, bank, or other approved channel. WooCommerce also documents that a refund for less than the full order amount does not change the order status to Refunded. WooCommerce refund documentation
Make the payment route explicit in the case record. For a gateway refund initiated in WooCommerce, capture the provider transaction reference and match it to the original charge. If the store records a manual refund after an operator returned money in the provider dashboard, attach that existing reference and mark it as externally executed. For an offline refund, attach the approved bank or tender evidence according to your controls. A blank provider reference on a manual case is a reason to investigate, even when the store balance looks right.
Choose one system or authorized team to initiate the money movement for each payment route. If WooCommerce or the gateway initiates it, verify that Acumatica’s selected workflow records the result without submitting another gateway request. If Acumatica is the approved initiator for a configured payment method, the store should reflect that outcome through the agreed workflow. Test the direction with your actual connector and processing center. An automatic refund in one application is not permission for a second application to refund the same charge.
Choose a system of record for each decision
Use WooCommerce to establish the storefront order and customer-facing refund detail. Use the payment provider to establish whether a particular charge was captured, what happened to the refund, and which balance transaction or payout carried it. Use Acumatica ERP for financial documents, customer applications, period posting, and inventory under your company’s controls. Use the bank statement to confirm that a specific payout or debit arrived.
The integration sits between those systems. Its job is to preserve the links and enforce the handoff rules. A successful import means data was handled; it should not be displayed as proof that the customer has been paid. In the same way, an Acumatica document that has been created but is still on hold should not be counted as a released credit in the period reconciliation.
Document who owns exceptions. Customer service should have a named route for a manual refund that lacks proof of payment. The warehouse should resolve an item reported as received online but missing from receiving. Accounts receivable should decide how to apply or correct a credit. The integration team should investigate stalled jobs, invalid mappings, or repeated events. Assign the next owner at the time of handoff, with an expected follow-up date.
The WooCommerce–Acumatica integration overview explains the wider storefront and ERP relationship. The refund process here narrows that relationship to the records finance needs to substantiate a reversal.
Capture the identifiers that survive a retry
Use the store identifier, original WooCommerce order ID, and individual refund ID as the core reconciliation key when the store creates the refund record. WooCommerce’s REST API documents individual order refunds with an ID, creation time, amount, and line detail. The same order can contain more than one such record. The API also distinguishes an API-triggered payment refund from a store record; that field is useful context, while the provider’s own transaction is the evidence for payment state. WooCommerce REST API: order refunds
Keep separate fields for the original charge, refund or void, merchant account, currency, settlement or balance transaction, and payout ID. Provider identifiers should be scoped to the relevant account and environment. Record the Acumatica tenant or company, branch, original order and invoice or cash sale, and resulting document types and references. Keep any return or receipt number and lot or serial detail when applicable. These links let a reviewer navigate from the bank back to the exact store event and vice versa.
If a refund begins in the gateway, create a provisional case using the merchant account and provider refund ID. When WooCommerce records the corresponding event, attach its store key to that same case. If the identifiers are missing, review the original charge, amounts, and timestamps together. Do not automatically join records on the customer name, order number alone, or amount. Two identical $25 credits can both be valid, and two stores may reuse the same display order number.
Record delivery IDs and the time of each import attempt as processing evidence. Use the refund key to control posting. A retry can have a different delivery ID without changing what the business event means. Conversely, a second partial refund on the same order should be recognized as new when it carries a new refund ID. Put a uniqueness rule at the point that creates or matches the ERP document, where two jobs could otherwise act at the same time.
Split merchandise, discounts, tax, and shipping
Compare the refund to the original transaction amounts by component. Merchandise is the net amount the customer paid for the returned items after applicable discounts. Tax, shipping, shipping tax, and refundable fees should have their own amounts and mappings. Keep both the source signs and a consistent reporting convention; an export may show a refund as negative while a clerk reviews the positive amount to be returned.
Use the original order lines and tax evidence for a credit. A promotion or tax configuration may have changed since the sale. Repricing a returned item using today’s product price or tax setup can leave the store and Acumatica disagreeing even when the gateway debits the expected total. Confirm the applicable tax and rounding policy with the controller for the relevant company, jurisdiction, and tax engine. Preserve the source allocation and explain any approved difference.
WooCommerce’s order refund API can carry a refund amount and component details. Its documentation also describes cases where a supplied total can take precedence over line totals. An amount-only refund may therefore need additional accounting evidence, even if its total is valid at the gateway. Require a reason, a supported allocation or approved adjustment account, and a reviewer before releasing an unexplained variance. WooCommerce REST API: order refunds
For a second partial refund, recompute what remains at both the order and line level. Check remaining refundable merchandise quantity, tax, and shipping, then compare the remaining captured amount for the tender being refunded. This catches a valid-looking total that is allocated to the wrong line or a request to refund shipping already credited on a previous event. Treat a retained processor fee as a settlement item, separate from the customer’s approved refund.
Keep warehouse disposition separate from the financial credit
A customer may be refunded before a parcel arrives, after inspection, or without sending an item back. Define when the refund can be authorized and what evidence is required before inventory becomes saleable. Record the expected quantity, the received quantity, the warehouse and location, the inspection decision, and any subsequent transfer or write-off. A stock count should follow the actual receipt and disposition.
For example, a customer sends back two units. The receiving team finds one fit to resell and one damaged. Both may qualify for the same customer refund, yet only the first should return to available stock under the approved policy. The second needs the configured quarantine, damage, or disposal path. The reconciliation should show which units were credited and where each unit went. This is especially useful when the refund date and warehouse receipt fall into different periods.
Decide which system publishes the authoritative quantity to WooCommerce. The Biz-Tech WooCommerce Connector product documentation describes warehouse selection and configurable quantity bases for outbound inventory synchronization. Validate the actual configuration before enabling restock actions in both systems. If a store refund increases WooCommerce stock and an ERP receipt is also used to drive the next availability update, test the timing and final sellable quantity. Look for a temporary increase as well as a permanent duplicate adjustment.
A shipping-only refund, a courtesy credit, or a returnless concession should have an explicit “no inventory movement expected” decision. This keeps the exception queue focused on cases where a receipt is actually missing. It also gives the warehouse a clear way to close the physical side of a case without waiting for settlement.
Choose the Acumatica document path from the original sale
Identify the original sales order, invoice or cash sale, payment or prepayment, and shipment status in Acumatica before deciding how to record the refund. A cancelled unshipped order, a paid invoice with a price adjustment, and a shipped stock item coming back may require different steps. Use your configured branch, order type, payment method, and release policy rather than copying a screen sequence from a different tenant.
Acumatica documents predefined Sales Orders return types for different outcomes, including return for credit, return for cash, and replacement. Where a physical return should produce a receipt and a credit, check the configured return type and the resulting financial and inventory documents. For a financial adjustment without goods coming back, use the finance-approved path and verify that it does not create an unintended receipt. Acumatica sales order type guidance
Acumatica’s accounts receivable documentation describes Refund documents on Payments and Applications (AR302000). A refund can be applied to eligible documents such as an open payment, prepayment, or credit memo, subject to the documented application rules. A released refund can still be open when it has an unapplied balance. That difference matters at close: capture both the release result and the application balance instead of treating a visible document number as completion. Acumatica refund and application guidance
When funds have already been returned externally, confirm that the chosen Acumatica action records or applies the refund without requesting a new card transaction. Test that behavior with the installed release and processing-center settings. The public documentation describes ERP document capabilities, while your connector and payment setup determine which events arrive and which actions are safe to automate.
Decide what the connector can safely automate
Start with the features the installed release demonstrably supports. The Biz-Tech WooCommerce Connector product page describes importing selected WooCommerce orders into Acumatica and synchronizing fulfilment and inventory information. That is a basis for linking the original sale. It does not establish that every gateway refund, partial line adjustment, dispute, or return condition is automatically posted and settled in your environment.
For each event type, walk through the expected store record, provider outcome, Acumatica document, and inventory disposition. Ask whether the connector receives individual refund IDs; whether it imports already executed refunds or initiates cash movement; how it handles partial refunds and repeated deliveries; and whether it creates, applies, or only proposes documents. Verify the behavior with a controlled sample. If the connector cannot provide a link or distinguish an event type, use a reviewed exception workflow until that gap is resolved.
Where a custom integration is needed, keep the evidence collection separate from the posting action. Read source records into a reviewable case, then allow an authorized action to create or release the appropriate ERP document only after the necessary checks pass. The Acumatica REST API and OData architecture guide provides context for separating operational writes from reporting reads. A low-volume store may find a reviewed daily import and payout match more appropriate than adding automated release immediately.
Retain the connector version, WooCommerce version, gateway plugin version, and Acumatica build with your test results. Repeat the payment and release cases after an upgrade, a new payment method, a warehouse mapping change, or a modification to the tax setup. A workflow proved for a domestic card payment in one branch is evidence for that scenario. Use separate test evidence for another tender, company, or settlement currency.
Ingest notifications without letting them post twice
Treat an order update or webhook as a signal to look up current source records. Do not assume a payload contains every refund or that it arrives after the original order or invoice is available. WooCommerce documents webhook topics, shared secrets for delivery verification, delivery logs, and the possibility of a webhook being disabled following failed deliveries. Use a scheduled completeness check alongside notifications so a missed delivery can be found and replayed. WooCommerce developer guidance on webhooks
A reliable process verifies the webhook signature before accepting the notification, records it durably, retrieves the authoritative refund record, then evaluates the reconciliation key. If the original ERP order has not imported, hold the case and retry the lookup. If a job times out during ERP creation, search for the linked document before trying a second write. A service can lose the response after the ERP saves the document, so a timeout alone is inconclusive.
Keep the intake timestamp, source creation timestamp, and latest observed payment status. When data arrives out of order, use the current provider record and the case’s saved state to resolve the sequence. An older “pending” notification should not send a completed case backwards. A newly reported refund failure or reversal, by contrast, needs an exception with evidence. Preserve the history rather than overwriting a completed accounting action.
Backfill using a documented overlap window so late updates are still reviewed. Replaying the window should find the same refund keys without posting duplicates. Log the last successful read, volume read, exceptions, and age of the oldest unresolved item. This gives operations a way to distinguish a quiet storefront from a stalled integration.
Review tender, currency, and payout timing separately
Reconcile the tender that actually funded the order. Where an order used a gift card and a card payment, document how the approved refund is split and which system restores each amount. Check the remaining eligible balance by tender and the expected evidence for each leg. A credit to a stored balance will have a different trace than a card refund. If a provider’s rules require a different treatment, document it and verify the returned value against the case.
Preserve the order currency, refund currency, processor settlement currency, and Acumatica base or document currency as separate fields when they differ. Compare like amounts before translating them. A provider may debit settlement currency on a different day from the original charge; retain the actual settlement amount and the exchange or fee detail available from the provider. Finance should approve the way exchange differences and rounding are recorded. An amount tolerance can cover a defined rounding rule after the cause is known; it cannot substitute for a missing refund transaction.
Gateway status and bank timing also answer different questions. For example, Stripe documents refund states, including cases where a refund is pending or fails. Treat those as examples of why the provider’s own status and events matter, and check the provider you use. A successful refund need not produce an individual bank debit. When it reduces a future payout, use the processor’s balance activity and payout details to explain the net bank transfer. Stripe refund documentation
Match payment activity to the net bank payout
Begin with the provider’s itemized balance activity. Match gross captures, refunds, fees, disputes, and other adjustments to the relevant settlement currency and merchant account. Compare the resulting net payout to the bank entry using a payout reference and date. In WooPayments, the payouts and transaction detail described in the Managing Money guide provide evidence for this step. Use equivalent reports for other gateways.
Reconcile the processor clearing balance separately from the bank transfer. A clearing account is a ledger account used to track payment activity until it reaches the bank. A practical roll-forward adds captures and other inflows to the opening balance, subtracts refunds, fees, payouts, and other outflows, and compares the result with the closing balance for the same scope. Align the report dates and time zone before comparing totals. If a processor uses separate balances, reserves, or currencies, reconcile them according to their own rules and show any transfers between them.
Bank-feed reconciliation can mark a $1,153.20 deposit as matched and still leave a missing $64.80 customer refund in the ERP. The balance movement tells you which activity reduced that deposit. Resolve the individual credit, refund, and settlement evidence first, then confirm the deposit matches the whole payout. Treat a processor fee retained on a refunded payment as a different line from the amount returned to the customer. WooPayments documents its fee treatment; review the applicable provider and method rather than generalizing it. WooPayments fee documentation
If the provider uses a negative balance, delayed payout, or a separate debit, retain the provider’s evidence for the outstanding amount and match the later transfer when it posts. An unexplained net difference should remain visible as an exception rather than being applied to an unrelated customer or written off as a fee.
Worked example: Two refunds on one order
The following numbers are illustrative and use USD. Assume the original WooCommerce order contains $180.00 of merchandise after discounts, $12.00 of shipping, and $15.36 of tax, including $0.96 on shipping. The customer paid $207.36 on one captured card charge. The order and invoice were fully shipped and released before the first refund. The example uses the amounts recorded for this fictional order and does not set a tax rule for other sales.
First refund: A returned item
On October 31, the store records refund 891 for one item with a net merchandise value of $60.00 and $4.80 of associated tax. The approved customer refund is $64.80. The provider records a completed $64.80 refund linked to the original charge. The warehouse receives and inspects one unit, records its disposition, and links the receipt to the original order and return case.
In the illustrative Acumatica setup, finance verifies the return and released credit and applies the recorded customer refund as appropriate for the original transaction. The posting stores the reference to refund 891 and the original payment. The cash movement already occurred at the provider, so the accounting workflow must not send a second gateway request. A delivery retry for refund 891 finds the same ERP references.
Second refund: A shipping adjustment
On November 4, customer service approves a $12.00 shipping refund plus the $0.96 shipping tax from the original order. WooCommerce records refund 912 for $12.96. The same captured payment has a second provider refund reference. Finance checks the approved shipping and tax accounts and links the adjustment to the original sale. The warehouse records no receipt or stock change for refund 912.
The two legitimate refunds total $77.76. Subtracting that from $207.36 leaves $129.60 of the original order value unrefunded, including the remaining tax in this example. Use the remaining amount and the component balances to check future requests. Do not collapse the two records into one merely because they share a charge and order. The first receipt and the first accounting date cannot stand in for the second event’s evidence.
Payout: Why the bank entry differs from the refund
Assume a November 2 payout includes $1,250.00 of eligible captures across many orders, the $64.80 refund from October 31, and $32.00 of processing fees. The illustrative deposit is $1,153.20: $1,250.00 minus $64.80 minus $32.00. Refund 912 is later and belongs to separate balance and settlement activity. Neither refund should be matched solely by looking for its amount on the bank statement.
At the October cut-off, the reviewer keeps the $64.80 refund in the appropriate accounting period under the company’s policy, with the open clearing evidence tying it to later settlement. The November bank match clears the related payout activity under that same policy; it does not create the October credit a second time. In November, the shipping refund follows its own event, posting, and payout trail. The ability to explain both timelines is what makes this case reviewable at close.
What if the October credit is missing?
Suppose the processor report shows the $64.80 refund and the bank deposit agrees, but the ERP search finds only the original invoice. Start with refund 891 and the provider’s refund reference. Look for a held document, an import error, or a credit entered under a different branch before creating anything. If no document exists, accounts receivable should approve the correction and its period. If October is closed, keep the original event date and explain the posting date in the close evidence. Acumatica documents settings that can assign an open period when creating a refund from a payment in a closed period; verify the actual dates assigned by your workflow. Acumatica refund and application guidance
The reverse discrepancy needs a different investigation. If the $64.80 credit was released but the provider has no completed refund, finance can explain the customer credit while payments confirms what happened to the funds. Hold any automatic retry until the payment team rules out a pending or externally executed transaction. The exception should show the ERP credit, the missing payment evidence, and the next responsible person.
Close exceptions by cause and owner
An exception queue should state what evidence is missing and what someone can do about it. A case labelled “refund mismatch” without the payment reference, remaining amount, or expected ERP record sends the next person back to the beginning. Include the business event key, affected amount and currency, current state of each applicable leg, last action, next owner, and expected resolution time.
- Payment status missing or unresolved: Customer service or payments checks the original charge and provider refund. Capture the actual outcome and escalate aged pending cases through the provider’s process.
- Source refund without an ERP record: Integration support checks whether the original order and invoice exist and whether branch, customer, tax, tender, and item mappings resolved.
- ERP credit without an application: Accounts receivable reviews the original document and open balances before applying or correcting it. Include release and financial period evidence.
- Wrong amount or currency: Finance traces each component, verifies tender and rounding, and documents the approved correction. Route an unknown cause to review.
- Receipt or disposition missing: Warehouse operations compares expected and actual quantity and identifies whether the return belongs in saleable stock, inspection, or another approved location.
- Unmatched payout or bank debit: Treasury or finance checks the provider’s itemized report, transfer status, settlement currency, and bank reference.
- Duplicate risk: Pause the posting path while support finds any existing refund, application, or gateway transaction. Resolve the linkage before replaying the event.
Use ageing thresholds that match the gateway’s timing and the business’s cut-off needs. Escalate potential duplicate payments immediately; monitor normal payout timing on a different clock. Close a case only when the required evidence is present or a named owner approves a documented treatment and carries the outstanding amount forward. If an exception is reopened, retain the original resolution and add the new reason.
Build a month-end review a second person can reproduce
Choose the close time zone and use it consistently across the storefront, gateway export, ERP, and bank. Record the source timestamps alongside the time used for the accounting cut-off. A late-night WooCommerce refund can be in one date range at the store and another in a UTC export. Keeping both values prevents apparent differences caused by comparing different populations.
Review the period with this sequence:
- Export the WooCommerce refund population and payment-provider movements using the agreed cut-off. Keep a copy of the files or saved report parameters.
- Compare counts and amounts by merchant account, currency, store, and branch. Separate refund requests, actual refunds, voids, disputes, and non-cash adjustments.
- Verify each applicable ERP document is linked and released in the expected period. Review unapplied balances and held documents separately from completed credits.
- Reconcile the provider clearing roll-forward, then match the payouts and debits to bank entries. List identified amounts still in transit.
- Match returned stock to the warehouse’s receipts and dispositions. Review cases where financial approval preceded inspection and assign an owner to missing evidence.
- Record the exceptions, their amounts, responsible people, approved treatments, and the opening items for the next period. Have the reviewer sign off on the evidence and any remaining differences.
Keep the population used for the review reproducible. Save the precise filters, report dates, store and gateway accounts, and who prepared and reviewed the close. Use reference IDs and controlled links rather than circulating unnecessary customer or card data in spreadsheets. On the next period’s first review, start with the unresolved cases carried forward. This keeps known timing differences from being lost in new activity.
Test the cases that can break the reconciliation
Run the test plan against the exact WooCommerce, gateway, connector, and Acumatica versions that will run in production. WooPayments provides a documented test mode for payment and refund scenarios. Use test data and the applicable test environment to validate event handling; confirm which payout evidence can be reproduced in that environment. Where a gateway’s test environment cannot represent real bank settlement, test the close bridge separately against a controlled report or approved historical example. WooPayments testing documentation
Begin with a paid and shipped order that receives one full refund and a valid return receipt. Then test two partial refunds on one order with separate IDs and one replayed event. Expect one posting per approved refund, two legitimate provider references, and only the expected inventory movements. Test a manual store refund whose provider reference is still missing. The case should remain open and must not initiate a second payment by itself.
Include a cancellation before capture, a captured order cancelled before shipment, a courtesy credit with no goods coming back, and a damaged item received into inspection. Test an unavailable original invoice, a bad SKU or branch mapping, a gateway timeout after document creation, a pending or failed provider refund, and an end-of-month case with later settlement. Include a mixed-tender or multicurrency order if the store accepts either.
For each case, record the expected amount and currency, stock effect, document links, application and release state, and settlement outcome. Pass the case only when actual results match and a reviewer can follow the evidence without searching by customer name. Before adding a second store or gateway, rerun the cases that change with that configuration. A successful first store pilot provides a test pattern, while each new payment route needs its own proof.
Measure the process by what stays unresolved
Track how long it takes a refund to acquire a provider reference, an ERP link, and a settlement link. Measure amounts and counts by stage, store, and currency. The gap between store recording and payment confirmation is useful for customer service; the gap between ERP release and the bank match is useful to finance. A single average for “refund processing time” can hide both kinds of delay.
Track the share of confirmed refunds without an ERP match, the count and value of released refunds with unexplained unapplied balances, and the value of unmatched payout activity. Also monitor duplicate attempts stopped by the integration and duplicate payments actually executed. A repeated event stopped by a uniqueness check is evidence that the control worked; a customer paid twice is an incident.
Establish the baseline before automating more cases. If unresolved records cluster around one payment plugin, one branch, or one mapping rule, fix that cause and repeat the relevant test. If volume is low and the exceptions are judgment-heavy, retain a review step for those categories. The business benefit comes from having fewer unexplained amounts and a shorter close review, which the team can measure from its own evidence.
Start with one store, one gateway, and one period
Choose a closed accounting period from one store and one payment provider. Select a routine refund, a manual refund or offline payment, a partial refund, and a refund that settled after the cut-off. Follow each through the four records. Make a short list of missing identifiers, unclear ownership, and any step that can create an extra payment or restock. Give the highest priority to gaps that could move money or affect available inventory.
Decide which cases can be matched automatically and which require approval. Write a release rule and an exception owner for each path, then rerun the selected period and compare the results. Once the team can reproduce the close, expand to the next store or payment method using the same checklist. Teams with both storefront platforms can use the Shopify refunds and cancellations guide for the Shopify-specific event and payment details.
Frequently Asked Questions
Does changing a WooCommerce order to Refunded return the money?
No. The status change itself does not initiate a refund. Use the supported gateway refund workflow or return the money through the approved manual channel, then verify the provider or bank evidence. WooCommerce refund documentation
How do I find partial refunds when the order status stays the same?
Review the individual refunds attached to the original order. Import or record their refund IDs and amounts separately. In WooCommerce, a partial refund need not change the whole order’s status to Refunded. WooCommerce refund documentation
Does a WooCommerce manual refund automatically create an Acumatica refund?
That depends on the deployed connector and configuration. The WooCommerce manual refund records an adjustment in the store. Verify any ERP import separately and obtain independent evidence that the customer was paid through the approved channel.
When should the ERP record a credit without returning stock?
A shipping concession, price correction, or returnless refund can require a financial adjustment without a warehouse receipt. Have finance select the appropriate ERP document and verify that the chosen path has the intended inventory effect.
Is a credit memo the same as a customer refund in Acumatica?
A credit memo and an A/R Refund are distinct document types. The correct application depends on the original sale, available balances, and whether funds were returned. Review the document and its application state in the applicable workflow. Acumatica refund and application guidance
Can a released refund still be open in Acumatica?
Yes. Acumatica documents that a released Refund can have an open balance if it has not been fully applied. Check the application and available balance before treating the case as closed. Acumatica refund and application guidance
How do I avoid a second refund when the gateway already paid the customer?
Assign one system to initiate the money movement for each route. Save the provider refund reference and use an ERP workflow confirmed to record or apply the outcome without submitting a new provider request. Look for an existing record before retrying after an uncertain result.
Why can’t I find the refund as a separate line on my bank statement?
It may have reduced a net payout that includes many orders. Find the refund in the processor’s itemized activity, trace the payout or debit it affected, and then compare that transfer with the bank entry. WooPayments balance and payout documentation
What if the refund posts in one month and the payout arrives in the next?
Keep the refund and settlement dates separately. Apply the approved period policy, show the amount in the clearing reconciliation at cut-off, and link it to the later payout once it reaches the bank.
What should we bring to a WooCommerce integration review?
Bring the installed versions, merchant accounts and payment methods, order and refund records, corresponding Acumatica documents, and an itemized payout sample with sensitive details removed. Include an ordinary partial refund, a manual case, and any unresolved month-end difference.
Sources
- WooCommerce: Refunding orders
- WooCommerce REST API: Order refunds
- WooCommerce developer documentation: Working with webhooks
- WooPayments: Managing money and reviewing payouts
- WooPayments: Fee policy and payment method notes
- WooPayments: Testing payments and refunds
- Stripe: Refunds and cancellations
- Acumatica ERP Help: Sales order types and return outcomes
- Acumatica ERP Help: Refunds and application rules
Biz-Tech Services can review the WooCommerce, payment gateway, and Acumatica handoffs with your operations and finance teams. Request a WooCommerce integration review and bring an example where the store refund, ERP credit, or payout does not yet tie out.
