Acumatica supports customer invoicing, payment collection, payment application, and receivables reporting. Its integrated payment offering also describes payment links and card or ACH acceptance through supported arrangements. Those capabilities connect the billing process with payments, but a customer invoice, an applied receipt, and a bank deposit remain different records. Acumatica Accounts Receivable, Acumatica Payment Processing
For a business evaluating the system, the central question is how those records relate. Can the team establish what the customer owed, what they paid, which invoices the payment addressed, and what ultimately reached the bank?
A clear answer helps both collections staff and accountants. It also prevents a dashboard status from being interpreted as evidence it does not provide.
The invoice needs to be collectible as well as accurate
An invoice can contain the correct arithmetic and still be difficult for a customer to process. Missing references, unclear descriptions, or delivery to the wrong contact can delay the next action.
Before choosing an invoice format, identify what customers need to recognize the obligation. That may include an order reference, a project identifier, or a breakdown that matches the agreed billing arrangement.
Test the complete communication using approved sample data. Confirm that the intended recipient can understand the amount and locate the appropriate route for questions. This is a proposed acceptance test, not a claim that every customer requires the same fields.
The billing team should also know how corrections are handled. A revised explanation and an accounting adjustment are not necessarily the same action, so the workflow needs to preserve the actual financial result.
A payment option depends on an enabled arrangement
Acumatica’s current payment-processing materials describe links that allow customers to pay by card or ACH, including full, partial, and multiple-invoice payments. The offered capability still needs to be matched to the customer’s software version, configuration, and payment-service arrangement. Acumatica payment-link capabilities
Ask the implementation team to demonstrate the actual proposed customer experience. Which document generates the request? What does the customer see? Which organization processes the payment? How does the result return to the accounting workflow?
The answers should include failures and interrupted attempts. A successful demonstration proves less if the business cannot determine what happened when a customer closes a page or receives an error.
Processing fees, approval requirements, settlement timing, and any account restrictions should come from the applicable service agreement. A product overview is not a merchant contract.
Payment application answers which debt was reduced
A customer payment must be connected to the relevant invoice or invoices if the team is to understand the remaining amount owed. Acumatica’s AR offering includes payment application and monitoring of open balances. Acumatica receivables capabilities
Consider a hypothetical customer with invoices of $1,200 and $800 who sends $1,500. If the supported, authorized application assigns $1,200 to the first invoice and $300 to the second, the remaining invoice balance is $500.
That example does not establish how every payment should be allocated. It shows why the team needs remittance information or another approved basis for the decision. A total receipt of $1,500 is insufficient to explain the status of both invoices without knowing the application.
Collections reports should reflect that distinction. A payment awaiting application can create a different operational question from a customer who has not paid.
Settlement can group activity differently
Acumatica describes settlement-batch visibility and the import of merchant fees and deductions to support reconciliation. This provides a connection between payment activity and bank deposits, subject to the implemented arrangement. Acumatica settlement and reconciliation
A hypothetical batch illustrates the accounting question. Suppose processed customer payments total $2,000 and a $40 processing fee is deducted from that same batch. With no other adjustments, the deposit would be $1,960. The difference is explained by the fee; it is not automatically an unpaid customer balance.
Some arrangements charge fees separately, and batches may contain other adjustments. Use the actual settlement evidence rather than assuming the illustration describes the company’s provider.
This is why matching every bank deposit directly to a single invoice can be the wrong starting point. The bank reconciliation guide examines how to identify the relevant grouping.
Refunds and credits also need distinct meanings
A credit changes the accounting relationship with the customer. A refund concerns money being returned through an authorized payment process. Depending on the circumstances, one may be needed alongside the other, but their existence should not be assumed from a single label.
Ask the implementation team to demonstrate the supported correction and refund cases relevant to the business. The resulting records should explain the original invoice, the adjustment, the payment action, and the remaining balance.
Do not infer that changing an invoice alone reverses an external payment. Confirm the actual workflow and the payment service’s rules before describing a refund as complete.
Give each unresolved question an owner
Customer-service staff may hear the first complaint, while AR holds the invoice and another team manages processor inquiries. Establish what information moves with the case and who remains responsible for the next action.
Useful starting questions include whether the customer is disputing the charge, reporting a failed attempt, asking about a duplicate, or questioning an outstanding balance. Those descriptions route the investigation without claiming a cause before it is established.
Keep payment credentials and full card details out of ordinary correspondence. The business should use its approved payment and support channels for any sensitive processing information.
Test the complete invoice-to-deposit story
Before accepting the workflow, ask the team to demonstrate a normal payment, a partial payment, and a case involving settlement fees or another relevant exception. For each case, establish what the customer sees and what the accounting team can verify.
Use the implementation guide to document the results and the reporting guide to define the status measures.
The practical standard is that another authorized person can trace the amount from invoice to payment application and then to the relevant settlement or bank evidence. That produces an explanation a customer can understand and an accounting record the finance team can defend.