Amazon and Acumatica settlement reconciliation means proving that marketplace sales, refunds, fees, adjustments, reserves, and the eventual bank deposit agree with the documents and accounts in Acumatica. The order import alone cannot establish that result. A seller needs a controlled bridge from each Amazon transaction to an ERP document, from those documents to the settlement statement, and from the statement to cash. Fulfilled by Amazon (FBA) and Fulfilled by Merchant (FBM) create different inventory and fulfillment records, but both can affect the same marketplace payout. This guide shows finance and operations teams how to set the reconciliation boundary, design the matching keys, work through a payout, resolve timing differences, and test the process before relying on it for close.
The article focuses on US Seller Central terminology, with principles that can be adapted to other marketplaces after checking local tax, currency, and reporting rules. It distinguishes the Biz-Tech Services Amazon Seller Central Connector from Acumatica’s native Amazon connector. Their published feature descriptions are different, particularly for settlement report import; verify the exact connector, version, and configuration in use before treating a screen or automation as available. Amazon Payments reports, the Biz-Tech connector listing, and Acumatica’s native Amazon connector provide the product boundaries used here.
Table of Contents
What a completed Amazon settlement reconciliation proves
Keep FBA and FBM fulfillment paths distinct
Identify which Amazon connector is actually installed
Choose the source reports and freeze the review period
Define a matching key before mapping amounts
Separate sales, cash, and marketplace clearing
Build a gross-to-net payout bridge
Match the payout to the bank without losing detail
Reconcile refunds and returns by event, not just order
Give fees and charges their own evidence trail
Treat reserves and deferred funds as timing items
Keep inventory reconciliation beside cash reconciliation
Resolve tax and currency boundaries before automation
Make exceptions actionable and aged
Prevent duplicates when events are retried
Design a repeatable daily and close cadence
Plan the reconciliation architecture for the installed stack
Create a manual settlement worksheet
Test with a representative settlement before rollout
Govern changes and incidents after go-live
Use a practical go-live checklist
Where Biz-Tech Services can help
Conclusion: make every payout explainable
What a completed Amazon settlement reconciliation proves
A complete reconciliation answers three questions with evidence. First, do the Amazon events in the chosen settlement period appear in the expected Acumatica documents or approved adjustment schedule? Second, do those events explain the settlement amount after fees, refunds, reserves, and other charges? Third, does the settled amount match a specific bank deposit or a documented in-transit item? These are separate checks. An order can be present in Acumatica while its payment is deferred, a fee has no order document, or the payout has not reached the bank.
Set the unit of review before calculating. A settlement ID, seller account, marketplace, currency, and period boundary should identify one review package. Keep the Amazon statement and transaction detail used for that package, the corresponding ERP reports, any manual mapping schedule, and the bank evidence together. If one seller account has several marketplaces or currencies, do not net them together until each component has its own trace. A reviewer should be able to reproduce both the gross-to-net bridge and the exception list using retained source exports.
Amazon describes its Payments reports as detailed activity for a settlement period, and its transaction view includes orders, refunds, fees, and Amazon-initiated charges and credits. The statement is therefore a source for the *payout calculation*, not simply an order sales report. Amazon Payments reports and Amazon transaction view guidance explain the available views. The accounting entries and reconciliation accounts remain a controller-approved design choice for the seller’s Acumatica setup.
Keep FBA and FBM fulfillment paths distinct
FBM means the seller fulfills the order. In the documented Biz-Tech flow, an FBM order can enter Acumatica as a sales order or invoice according to store settings; when the sales order route is used, the seller’s warehouse ships and invoices it. FBA means Amazon fulfills from stock sent to its fulfillment centers. The Biz-Tech flow describes FBA stock movement through transfer orders and receipts and imports FBA customer sales as invoices. The Biz-Tech workflow guide and connector listing describe those paths.
Reconciliation should retain the fulfillment channel on each order line because the operational evidence differs. For FBM, the seller can compare its shipment and tracking record with the imported order and marketplace charge. For FBA, Amazon’s fulfillment and fee activity must be considered alongside the imported invoice and the movement of stock into an Amazon location. The cash bridge may combine both channels in one settlement, but the inventory proof cannot. A bank deposit that matches the settlement amount says nothing by itself about the quantity remaining in a fulfillment center.
Build a shared order key from the seller account, marketplace, Amazon order ID, and any line or shipment identifier needed for partial events. Store the fulfillment channel as a separate field, not an assumption inferred from warehouse or customer. If order import settings allow a default customer for one channel and customer creation for another, avoid matching only on customer name. The Biz-Tech customer mapping lesson explains that FBM and FBA have separate customer handling options.
Identify which Amazon connector is actually installed
The word “Amazon connector” does not name one universal feature set. Biz-Tech’s Acumatica Marketplace listing describes orders, customer and item data, payment information, fulfillment, inventory, and FBA flows. Its current public listing does not explicitly promise automated Amazon settlement-report import or the native connector’s bank transaction workflow. Biz-Tech’s own Amazon Connector page emphasizes governed order, fulfillment, inventory, and refund processing. Confirm any settlement-specific capability directly against the installed Biz-Tech package and its documentation.
Acumatica’s native Amazon connector is a different product. Acumatica advertises settlement-report integration into the bank transaction workflow for that connector and describes order-related fees and payments for FBA invoices. Its product page also covers FBA and FBM operational flows. Those claims belong to the native connector and should not be copied into a description of Biz-Tech’s package. See Acumatica’s native Amazon connector and its Amazon connector product sheet.
Inventory the installed customization, Acumatica build, enabled entities, seller accounts, import screens, and financial posting rules before designing the reconciliation. Record whether settlement details arrive automatically, through an approved custom import, or through a controlled manual file. If the team uses both connectors or has replaced one, document which owns each transaction family so the same Amazon event cannot create duplicate ERP documents.
Choose the source reports and freeze the review period
Start with the Seller Central Payments statement for a specific period and download its detailed report. Amazon offers statement downloads and, for applicable FBA sellers, a Flat File V2 option; its help page explains where reports are found and what the statement shows. Use transaction detail to inspect order-level activity, refunds, service fees, and other charges. Keep both the original file and the filtered working copy so a reviewer can re-create the result. Amazon: download payment reports.
Define the cutoff in the source system’s terms, not only by calendar month. A settlement period may cross the month end, and activity may be deferred or released at a different time from the order date. Record the statement identifier, start and end timestamps, time zone, currency, download time, and any excluded account or marketplace. Amazon’s transaction view documentation distinguishes transaction types and describes statement-period and custom-date filters. Amazon transaction view guidance.
For a month-end close, make two views. A period-by-settlement view explains cash. A period-by-transaction or posting-date view explains financial activity recognized in the month. The two may differ without either being wrong. List each difference as a timing or classification bridge with a source ID and expected clearing period. Never silently move a transaction to the payout month merely to force the trial balance to agree with the bank.
Define a matching key before mapping amounts
A transaction match needs more than an amount. Two orders can share the same total, and one order can generate multiple charges, refunds, or fee events. A robust key combines seller account, marketplace, source transaction or order ID, event type, currency, and—where necessary—line, shipment, refund, or settlement ID. The ERP document reference and status should be stored beside the source key. The matching rule should define what happens when Amazon changes an event after its initial import.
Build a one-to-many mapping explicitly. One Amazon order may correspond to a sales order, shipment, invoice, payment, return, and credit memo over time. One settlement can contain many orders plus account-level fees and reserves that have no single order document. A matching design that expects one Amazon row to equal one invoice will misclassify ordinary fee and refund activity as missing data. Conversely, a design that matches only settlement totals can hide duplicate or misapplied order records.
When an API-based feed is used, validate the exact fields in its current version. Amazon’s Finances API documentation describes financial events, date-range access, and a use case for determining which transactions comprise a payment. That capability is an Amazon data source, not proof that a particular Acumatica connector already imports or maps every field. Keep the raw Amazon identifier in the integration record even if users normally search by a shorter ERP number.
Separate sales, cash, and marketplace clearing
The gross order value, the amount Amazon owes the seller, and the cash received are three different measurements. An Acumatica invoice may represent a sale. Amazon’s settlement then reflects payment-related activity, deductions, and adjustments. A bank transaction records the net payout. Design a clearing or receivable process that makes those stages visible, with account names and posting timing approved by the controller. Do not use the bank deposit itself as the only sales entry; that would obscure fees and refunds.
At minimum, define how sales, sales tax, marketplace-collected tax, customer refunds, referral fees, FBA fees, storage or subscription charges, reserves, reimbursements, and net payout are recognized in the seller’s specific accounting policy. Tax treatment varies by jurisdiction and marketplace program; a settlement line is not enough to decide the legal tax liability. Have the controller validate whether a line is revenue, a liability, an expense, or a movement within clearing accounts before automating its mapping.
Acumatica’s native Amazon connector describes a settlement workflow that produces transactions for matching in its bank transaction process. That is one possible implementation. A seller using Biz-Tech’s connector may instead need a separate verified feed or controlled import for settlement lines. The common control is the same: the beginning balance plus signed activity and reserve movements must explain the ending amount, and the ending amount must map to a bank deposit or an open item. Acumatica native connector overview.
Build a gross-to-net payout bridge
Use a signed schedule that starts with the statement’s beginning balance, adds positive activity, subtracts charges and refunds, accounts for reserve transfers, and arrives at the expected payout. The column labels should come from the actual Amazon report, but the review schedule can normalize them into stable categories. Keep individual source rows beneath each category so a total can be traced back to orders or fee events. Do not collapse “other” until the amount has been classified and approved.
Here is a hypothetical illustration, in one currency and one seller account, with a zero opening balance. It is a teaching example, not an Amazon statement format or a prescribed journal entry: customer receipts of 10,000; refunds of 800; referral fees of 1,500; FBA fulfillment fees of 600; storage and other charges of 200; a reserve increase of 500; and a release of a prior reserve of 100. The expected payout is 6,500: 10,000 − 800 − 1,500 − 600 − 200 − 500 + 100. If the bank shows 6,500 and the associated ERP documents and approved fees support those categories, the cash bridge agrees. If the bank shows 6,450, the 50 difference remains an exception until identified or confirmed as in transit.
The calculation is deliberately separate from a sales-income calculation. The 10,000 could contain components that require different accounting treatment, and the refund timing could differ from the original sale. Review the underlying order, tax, and payment fields before posting. Amazon’s transaction view lists a range of charges, credits, and reserve-related items that make a single “sales less fees” shortcut unreliable. Amazon transaction view guidance.
Match the payout to the bank without losing detail
After proving the statement amount, locate the related deposit in Acumatica’s bank or cash account. Match using the amount, currency, settlement or transfer reference, expected date, and bank description. Record the source statement ID on the reconciliation evidence even when the bank feed truncates the description. If the deposit is not yet present, leave a dated outstanding item and review it again after Amazon’s transfer and the bank’s posting windows have passed.
Amazon notes that its settlement report can carry an ACH trace ID and that a bank can use it to research a delayed transfer. That reference is useful when the statement is closed but the deposit is missing. A statement saying a transfer is expected is not the same as cash recorded by the bank. Amazon: download payment reports. The seller’s bank feed and Acumatica configuration determine the practical matching fields.
Do not post a second revenue entry when matching the payout. The bank step clears the marketplace receivable or settlement clearing balance established by the transaction posting design. If the account does not clear to zero, investigate the source rows: an omitted fee, a duplicate refund, a reserve movement, a currency conversion, or a posting date difference can all explain a residual. Preserve the residual with its reason and owner rather than forcing a bank adjustment for convenience.
Reconcile refunds and returns by event, not just order
A customer order and a later refund can appear in different settlement periods. The refund can be partial, can cover shipping or tax differently, and may be followed by a return or reimbursement. Match each refund event to its original order, payment, ERP credit or customer refund document, and settlement transaction. Track the amount already refunded so a second valid partial refund is distinguishable from a duplicate retry. The event date and the accounting period should remain visible.
Biz-Tech’s published Amazon workflow describes importing Amazon-originated refunded orders and producing a customer refund or credit memo depending on the original document’s status. That is an order-level operational flow. It should be reconciled to the actual settlement debit separately; an ERP credit memo does not by itself prove that Amazon deducted the cash in the expected payout. Biz-Tech Amazon data flow guide. Amazon’s transaction view identifies refunds as a separate type of account activity. Amazon transaction view guidance.
Record three outcomes for each return: financial refund, inventory disposition, and any seller reimbursement. FBA and FBM may have different physical return paths, so an inventory receipt should not be inferred from a negative settlement line. A refund without a corresponding stock movement can be correct in some situations; it needs a reason, not an invented balancing receipt. Escalate unexplained or duplicate refunds to the process owner before close.
Give fees and charges their own evidence trail
Amazon fees can be linked to an order, a service, a shipment, or the seller account. A referral fee might be associated with a sale, while a storage or subscription charge may have no order ID. Map each category to a reviewed expense or adjustment rule and retain its Amazon transaction ID, fee type, currency, amount, and settlement ID. A fee schedule should identify which categories are imported automatically, which need manual review, and which are deliberately excluded from the integration.
Do not assume that a connector importing payment information also imports every marketplace fee. The Biz-Tech listing names payment information, but the publicly described feature list does not establish comprehensive settlement fee import. Acumatica’s native connector separately advertises settlement-report and fee visibility. The installed package and mappings determine the actual coverage. Biz-Tech connector listing and Acumatica native Amazon connector.
Review unusual or newly appearing fees as exceptions before assigning a permanent posting rule. A broad “miscellaneous Amazon fee” account can get the bank to balance but hide changes in cost of selling. Keep the source label, a reviewed accounting category, and the effective date of each mapping. For large or disputed charges, link the Seller Central case or adjustment evidence to the reconciliation package.
Treat reserves and deferred funds as timing items
Amazon can hold or release amounts across settlement periods, so the current payout may contain a reserve release from an earlier statement or exclude a current-period amount held back. Track reserve increases and releases in a roll-forward: opening reserve, new holds, releases, and closing reserve. The closing balance should agree with the source statement or a documented difference. A reserve is not a missing bank deposit merely because it reduces the payout.
Amazon’s transaction guidance includes reserve-related activity and prior-period amounts as account transactions. Its Payments guidance distinguishes the expected settlement amount from the detailed transactions that produced it. Amazon transaction view guidance and Amazon Payments reports. Translate those concepts into accounts only after the controller approves the seller’s treatment and confirms how the marketplace report exposes them.
Deferred funds also change matching order. An order can be imported into Acumatica before the associated financial event becomes available for payout. Do not mark the order as unreconciled forever or assume it was paid because a payment field exists. Give it a status such as awaiting release, with the source order ID, expected review date, and a rule for escalation if the release does not occur. The same logic applies when a refund posts after the original order’s settlement.
Keep inventory reconciliation beside cash reconciliation
FBA and FBM settlement review can expose inventory questions, but it cannot answer them alone. For FBM, compare order shipment quantity with the seller’s warehouse issue and any return receipt. For FBA, compare quantities transferred to Amazon, quantities acknowledged or received by Amazon, orders fulfilled, returns, adjustments, and remaining stock at the mapped fulfillment location. Review the timing and source of each movement before treating a discrepancy as shrinkage.
Biz-Tech’s Amazon inventory synchronization lesson describes separate FBM quantity publishing and FBA shipment, delivery, and order flows. It notes the importance of store, SKU, warehouse, and quantity-basis mappings. Those controls support the physical side of the reconciliation, while the Seller Central Payments statement supports cash and charges. Acumatica’s native connector also describes FBA inventory visibility, but its exact workflow belongs to that product. Acumatica native Amazon connector.
Use a combined exception register when the same event affects cash and inventory. A refunded FBA order might require financial correction, return disposition, and a possible reimbursement claim, each with different timing. Assign the financial item to finance and the stock item to operations or inventory control, then keep their source references linked. A matched payout should never automatically close an open quantity discrepancy.
Resolve tax and currency boundaries before automation
Amazon marketplace tax activity may be represented differently from seller sales and fees. The Biz-Tech connector listing says sales tax can be imported, but the specific fields and accounting outcome depend on store settings and tax configuration. A controller or tax adviser must determine whether a source amount is seller-collected tax, marketplace-collected tax, a liability, an informational field, or a correction. Match the settlement report to the ERP tax records without inventing a universal entry. Biz-Tech connector listing.
Currency adds another bridge. Store the source transaction currency, settlement currency, bank currency, exchange rate source, and any marketplace conversion fee separately. A same-currency settlement can be matched directly by amount; a converted payout needs an approved rate and a review of realized exchange differences. Do not net multiple currency statements in a spreadsheet before matching them to their deposits, because a balanced grand total can conceal one missing payout and one unrelated overstatement.
Document these boundaries at onboarding. The seller account, marketplace, legal entity, bank account, tax registrations, and Acumatica branch must line up. If one seller account serves multiple ERP entities, specify an allocation rule and the evidence that supports it. If the team cannot prove the allocation from source data, keep it as an explicit manual close item until a verified process is agreed.
Make exceptions actionable and aged
An exception is useful only when someone can resolve it. Record the source transaction ID, order ID when present, settlement ID, amount, currency, fulfillment channel, expected ERP record, actual ERP record, reason, owner, next action, and age. Separate “not imported,” “imported but unreleased,” “fee unmapped,” “refund pending,” “reserve timing,” “bank in transit,” and “bank amount differs.” Those categories point to different teams and should not all be labeled “sync error.”
Create a tolerance policy that distinguishes routine rounding from material differences, and have finance approve it. Never use a tolerance to discard unmatched source records. A small count of high-value rows may deserve faster escalation than hundreds of harmless timing items; the review cadence should reflect risk and close deadlines. Retain both the initial mismatch and the final correction so the team can show how the reconciliation was resolved.
For Biz-Tech connector operations, its data-flow guide describes import grids, error indicators, trace information, processing status, and last-imported dates. These are useful for finding where an order or refund stopped. They do not replace the settlement statement or bank evidence. If a financial line has no matching ERP document, first determine whether the line is an order event, a non-order fee, or a timing item before retrying an import.
Prevent duplicates when events are retried
Retries are normal when a service times out or a processing job is interrupted. The risk is that the source event may have succeeded even when the caller did not receive confirmation. Replaying it without checking the source key can create a second invoice, refund, fee, or clearing entry. Define a durable uniqueness rule for each event type, and keep the matched Acumatica reference in a location the integration or operator can consult before retrying.
Test the ambiguous case deliberately in a non-production environment: process a representative event, interrupt the response, and then rerun the retrieval. Verify whether the existing document is recognized, whether the event is skipped with a clear reason, or whether it is routed for review. Never assume that identical amounts and dates identify the same event. Two legitimate partial refunds can be the same amount; one refund replay can occur days later.
If a duplicate has already posted, resolve it through an approved reversal or correction that preserves an audit trail and the original settlement reference. Deleting the visible duplicate without confirming its accounting effect or downstream application can make the payout match while leaving the ledger wrong. The reviewer should verify the correction in the relevant accounting period and re-run the affected settlement bridge.
Design a repeatable daily and close cadence
Daily work should detect missing imports, new fee types, pending refunds, and approaching settlement dates. A compact control report can show eligible Amazon orders, imported ERP documents, failed or skipped records, oldest exception, and unmatched transaction value by seller account. The aim is early triage, not prematurely forcing an open settlement to balance. Finance and operations should agree on what “expected today” means for each event family.
When a settlement closes, freeze the source file, reconcile the statement to its transaction detail, match it to ERP activity, and track the bank deposit. At month end, review settlements that straddle the cutoff, deferred events, open reserves, outstanding deposits, unmatched refunds, and unresolved inventory movements. Retain the signed review package with its timestamp, source filters, preparer, reviewer, and corrections. This allows a second person to reproduce the result rather than trusting a screenshot of a green status.
Quarterly, review mappings, access, new seller accounts, bank accounts, currency handling, and connector changes. A new Amazon fee or modified API response can alter accounting even when order imports continue to succeed. The team should compare the live integration to the documented design and rerun affected scenarios after an upgrade or significant store configuration change.
Plan the reconciliation architecture for the installed stack
There are several legitimate paths from source data to Acumatica, but each needs its own boundary. With Acumatica’s native Amazon connector, confirm whether the Settlement Report entity and bank transaction workflow are enabled and supported in the installed build. With Biz-Tech’s connector, confirm its current documented settlement scope; if the package covers orders and refunds but not detailed settlement lines, add an approved financial feed or controlled manual import rather than attributing native-connector features to it.
The Acumatica native connector page advertises settlement integration. The Biz-Tech Marketplace listing describes its own operational feature set. Amazon’s Finances API is a possible source of financial events for a separately designed integration, with its access roles and data model needing validation. These sources establish possible ingredients, not a promise that all can be switched on in any existing tenant.
Write down the source of each data family: orders, payments, refunds, account fees, reserves, settlement totals, FBA inventory movements, and bank deposits. For every family, assign a technical custodian, business owner, refresh frequency, and correction path. A diagram of those sources is useful only if it also shows where a human approves a posting rule and where an exception waits when a match fails.
Create a manual settlement worksheet
Before testing automation, run a manual worksheet for one source statement. The worksheet should preserve every Amazon row with its original transaction type and identifier, then add review columns for normalized category, fulfillment channel when applicable, matching Acumatica document, accounting status, expected settlement effect, bank-match status, reviewer, and exception reason. A filterable worksheet is a working aid, not a replacement for the original statement. Lock or archive the source export separately so formula edits cannot alter the evidence.
The preparer first confirms that source row counts and signed totals in the working sheet agree with the downloaded statement. Next, the preparer groups rows by category and tests the gross-to-net bridge. Only then does the matching pass attach Acumatica references. This order matters: if the source import into the worksheet is incomplete, apparently unmatched ERP documents may be a file problem rather than an integration problem. A second person should independently recalculate the statement total from the retained rows and review any manual reclassification.
Use a clear state for each row: matched, documented timing item, open exception, or excluded with an approved reason. “Matched” should mean that the source amount and currency, relevant identity, and accounting effect agree, not merely that a similar number exists in Acumatica. For an account-level fee without an order ID, matching to an approved fee posting is legitimate if its transaction reference and category are retained. For an order-related refund, the original order and the new refund event both matter. Do not make a fee look matched by attaching it to an arbitrary order with the same amount.
Close the worksheet with a signed control block: settlement ID, seller account, source period, source totals, ERP total, expected payout, observed bank amount, open difference, preparation date, reviewer, and location of supporting files. If the payout is in transit, state the expected follow-up date and transfer reference. This compact package can later become the acceptance test for an automated reconciliation feed; it establishes the correct result before implementation details are allowed to obscure it.
Test with a representative settlement before rollout
Choose a closed settlement that contains both FBA and FBM orders if the seller uses both channels. Include at least one refund, an order-related fee, a non-order fee, a reserve movement, and a bank deposit. If any case is absent from recent history, use synthetic or approved test data in a non-production environment and label it as such. The test should compare Amazon source rows, imported ERP documents, the gross-to-net calculation, and cash, not just whether an API call returned successfully.
Write expected outcomes for ordinary and adverse scenarios. Test a partial refund, a refund crossing settlement periods, a duplicated retrieval, an unmapped fee, a transaction without an order ID, a delayed bank deposit, a currency difference, and an FBA inventory movement with a quantity mismatch. For each, record the expected document, account effect, exception reason, reviewer, and evidence. Confirm that a retry does not duplicate a posted event and that a correction does not erase the original trail.
Have the controller sign off on posting classifications and tolerances, the marketplace operator sign off on Seller Central source selection, and the inventory lead sign off on FBA/FBM stock behavior. Note the exact connector and Acumatica versions tested. A passing test proves those scenarios in that configuration; it is not a guarantee that a later API, connector, bank feed, or tax setting change will behave identically.
Govern changes and incidents after go-live
Treat a settlement mapping as controlled financial configuration. Changes to a seller account, marketplace, currency, fee category, refund handling, tax mapping, bank account, connector version, or Acumatica posting rule should have an owner, effective date, test evidence, and rollback plan. Keep the prior mapping available for historical statements. Otherwise, reprocessing an older settlement may apply a newer rule and produce a different result without explanation.
If an integration or report fails, first establish the affected date range, seller account, transaction families, and last known successful import. Preserve the source files and logs before changing mappings. Pause automated replay when duplicate financial effect is possible. Process a bounded sample after the fix, then reconcile the entire gap period, including records that did not raise a visible error. Close the incident only when the ERP documents, statement, and bank evidence agree or every residual has an owner and expected resolution.
Business decisions remain with the appropriate owner. Integration support can diagnose why an event failed to arrive; finance decides its account treatment; operations decides stock disposition; the controller approves material overrides. Document the decision and the associated source reference so a future reviewer can understand it without reconstructing the incident conversation.
Use a practical go-live checklist
Before relying on the process for close, confirm that every seller account, marketplace, currency, legal entity, and bank account has a documented owner. Verify the installed connector and its settlement feature scope. Approve source reports, cutoff, matching keys, posting categories, reserve treatment, and fee classifications. Test both FBA and FBM order paths, including refunds, returns, and stock movement. The relevant personnel should know where import errors and transaction detail are reviewed.
Next, prove one closed settlement end to end. Retain the original Amazon report, the normalized working schedule, the ERP document list, the bank transaction, and an exception register. Recompute the gross-to-net bridge independently. Confirm that a small unresolved line is visible rather than hidden by a balancing entry, and that a known timing item carries a due date. Run a duplicate retrieval test before allowing automated retries.
Finally, schedule the first live reviews and name a backup reviewer. Specify what stops a payout from being marked reconciled, how bank delays are escalated, and who can change mappings. Set a post-launch review date to compare the documented process with actual exceptions. A checklist item should point to evidence or an owner, not merely a checkmark.
Where Biz-Tech Services can help
Biz-Tech Services publishes an Amazon Connector for FBA and FBM order, fulfillment, inventory, and refund workflows in Acumatica. A reconciliation engagement can start by identifying the installed integration, mapping one settlement’s Amazon transactions to ERP documents, reviewing how fees and reserves are handled, and defining the unmatched-item queue. That assessment should expose whether the current stack already provides the necessary financial data or needs a separate supported import.
The useful outcome is a reproducible close process: finance can explain a payout, operations can trace the corresponding orders and stock, and support can locate failed or duplicated events. Confirm current connector capability, supported builds, and the exact requested scope with Biz-Tech before planning any automation. The Biz-Tech Amazon data-flow article, inventory lesson, and customer mapping lesson provide related operational detail without replacing settlement evidence.
Conclusion: make every payout explainable
Amazon and Acumatica settlement reconciliation succeeds when one identified Amazon statement can be traced through transaction detail to Acumatica documents, approved fee and reserve entries, and a bank deposit or dated outstanding item. FBA and FBM must keep their distinct fulfillment and inventory evidence even when their cash activity appears in the same payout. The installed connector’s feature scope matters: Biz-Tech’s public listing and Acumatica’s native connector describe different capabilities, so the team should validate the actual stack before assuming settlement lines are imported automatically.
Start with one recent closed settlement. Preserve its source reports, define the matching keys, build the signed gross-to-net bridge, identify missing or duplicated ERP records, and confirm the bank deposit. Assign each residual to a finance, marketplace, inventory, or integration owner with a due date. Once that package can be reproduced by a second reviewer, extend the process to additional seller accounts, periods, and automated feeds under the same controls.
Frequently Asked Questions
Is an imported Amazon order enough to reconcile its payout?
No. The order proves that an operational or financial document was created. The settlement may also contain refunds, fees, reserves, adjustments, and timing differences, while the bank deposit is a separate event. Reconcile the source detail, ERP documents, statement total, and cash.
Do FBA and FBM require separate reconciliations?
Keep separate fulfillment and inventory evidence for each channel. If Amazon combines their financial activity in one seller-account settlement, use one payout bridge with a channel field on order-related rows and separate exception views. Do not infer FBA stock from cash.
Does the Biz-Tech Amazon Connector automatically import settlement reports?
Its current public Marketplace feature list describes orders, payments, inventory, fulfillment, and FBA flows but does not explicitly promise automated settlement-report import. Verify the installed package and any custom extensions with Biz-Tech. Acumatica’s native Amazon connector separately advertises settlement integration.
Which Amazon report should the team preserve?
Preserve the settlement statement and the detailed transaction report used for the review, with the seller account, settlement ID, date range, currency, and download time. Use the exact report version available in that Seller Central account. Keep the raw file as well as any normalized working schedule.
Why can the bank deposit differ from gross Amazon sales?
The payout may include refunds, referral and fulfillment fees, other charges, reserve holds or releases, and activity from different dates. Reconcile the signed components in the statement before treating the difference as a missing payment.
How should a refund in a later settlement be handled?
Match the refund event to the original order and ERP correction, then to the later settlement debit. Keep both period dates and the refund’s unique identifier. Do not change the original payout merely to make the later refund disappear.
What happens if Amazon shows a fee with no order ID?
Classify it as a non-order charge using its own source transaction reference, settlement ID, fee type, amount, and currency. Route an unmapped type to review rather than forcing it onto an unrelated invoice.
How do reserves affect the calculation?
A new reserve hold reduces the current payout; a release adds to it, subject to the statement’s presentation. Maintain an opening-to-closing reserve roll-forward and confirm the exact signs against the downloaded report.
When is a settlement complete if the bank deposit is late?
The statement-to-transaction bridge can be complete while cash remains in transit. Keep a dated outstanding item with the settlement or ACH trace reference and confirm the bank credit when it arrives. Escalate a delay under the seller’s policy.
Can the same Amazon event be imported twice?
It can happen if a retry is not safely matched to an existing ERP document. Use stable source identifiers, test ambiguous timeouts, and review before replaying refunds or financial adjustments. Correct duplicates with an auditable reversal.
Who should approve the accounting mapping?
The controller or designated finance owner should approve account treatment, tolerances, period cutoffs, and material overrides. Integration support maintains the technical mapping, and marketplace and inventory owners validate source events and stock effects.
Sources
- Amazon Seller Central: Download payment reports
- Amazon Seller Central: Transaction View and statement activity
- Amazon Selling Partner API: Finances API
- Acumatica Marketplace: Biz-Tech Services Amazon Seller Central Connector
- Biz-Tech Services: Amazon Connector
- Biz-Tech Services: How Amazon FBA and FBM Data Flows into Acumatica ERP
- Biz-Tech Services: How to Sync Amazon Inventory with Acumatica
- Biz-Tech Services: How to Map Amazon Customers and Marketplace Orders
- Acumatica: Amazon Native Connector
- Acumatica: Amazon Connector product sheet
Biz-Tech Services can help sellers review the actual Amazon-to-Acumatica flow and build a reconciliation process around their configured connector, accounting policy, and operating teams. Begin with one closed payout and its unresolved differences.
