Batch payment application, customer statement generation, emailed PDFs, and OAuth SMTP — what mid-market distributors actually need from a receivables module, and why QuickBooks usually isn't it by the time you hit 100 active customers.
Accounts receivable is where growing wholesale distributors quietly bleed time. Not in the big-picture sense of unpaid invoices and aging AR buckets — distributors already track those. The hidden cost is in the mechanical work of applying payments, producing statements, and getting those statements in front of customers who owe you money. A distributor with 300 active customers and 1,500 open invoices burns hours per week on this, often with one person manually typing check applications into QuickBooks one invoice at a time. Then month-end arrives, statements need to be printed and mailed or attached to individual emails, and that person loses another day. This post walks through what AR automation actually looks like when the ERP is built for distribution — and why the biggest wins come from three specific workflows: batch payment application, customer statement generation, and emailed delivery.
For wholesale distributors, AR automation means the ERP handles the three mechanical steps of the receivables cycle without manual per-invoice data entry. Specifically:
These sound like basic features but the gap between "the ERP technically supports them" and "the workflow actually saves time" is where most platforms fall short. The sections below cover each workflow in depth and the specific pitfalls to watch for when evaluating options.
A wholesale customer sends one check for $12,847 covering 14 open invoices from the last 60 days. On paper, this is a trivial transaction. In most accounting software, it is an exercise in tedium: you open the customer, open each invoice one at a time, type in the amount to apply, and submit. Fourteen separate entries, each a chance to transpose a digit.
A distributor-built ERP handles this as one operation. You load the customer, see all 14 open invoices in a grid, enter the check total, and either click Auto to distribute oldest-first against balances or type per-row amounts. When you click Apply, a single database transaction inserts 14 receipt records, updates 14 invoice balances, and updates the customer master balance — all with one shared reference number so the batch is traceable. If any step fails, all 14 roll back together. There is no half-applied check sitting in the system waiting for manual cleanup.
The specific pain point this eliminates is the Clipper-era "one invoice at a time" pattern that a lot of legacy accounting code inherited. Many small-distribution ERPs still require you to apply a lump-sum check invoice-by-invoice. Some don't even let you reference them together, so a later audit can't reconstruct which payments were part of the same remittance.
When evaluating a batch payment feature, ask the vendor for a live demo with a real multi-invoice check. Watch how many clicks it takes from customer load to commit. If the demo requires 14 screens for 14 invoices, that is what your AR clerk will experience every day.
Statements are the second half of the AR cycle — the monthly push that drives customers to actually send those checks in the first place. A distributor with 300 active customers and variable credit terms needs to produce statements reliably, filter to customers with balances worth collecting on, and distribute them at scale without a person sitting at a printer for two hours.
A distributor-fit statement generator supports three modes:
The filters matter. "Statement cutoff days" — the number of days before the statement date to include transactions — determines whether you are sending a true month-end statement or a rolling 30-day view. "Only customers with a balance" trims noise. Per-route or per-salesman filtering turns statements into a collections tool the sales team can act on. Generic accounting software often gives you one or two of these filters; a distribution-fit system gives you all of them.
For AR strategy context beyond the mechanical generation, see AR Collections Best Practices for Wholesale Distributors.
Printed statements get lost in mail rooms. Faxed statements stop being a thing years ago. Emailed statements work — if you can actually send them reliably.
The email side of AR automation has quietly become harder, not easier, over the last few years. Gmail and Microsoft 365 both deprecated basic-auth SMTP for most configurations. If you want to send email from your ERP using a real business address (yours@yourdistribution.com, hosted on Google Workspace or Microsoft 365), you now have to either generate app-specific passwords (fragile and per-user) or use OAuth 2.0 (correct but harder to integrate).
An ERP with OAuth SMTP support lets you authorize the ERP once, store a refresh token, and send mail from there indefinitely without a stored password anywhere in your configuration. Gmail, Microsoft 365, and any modern OAuth-capable SMTP provider work the same way. Every outbound email — invoice, statement, order confirmation — gets logged to an email log table with recipient, subject, timestamp, document reference, and success status, so you have a complete paper trail of what was sent and when.
The alternative — running your ERP on an old-school SMTP configuration with a stored password — works until your IT team turns off legacy authentication, which at this point is inevitable. An ERP that requires legacy SMTP is technical debt you inherit on day one.
Payments get voided. A check bounces, a customer disputes an application, a clerk applies the wrong check to the wrong invoice. When that happens, the ERP needs to reverse the transaction atomically — insert a void marker on the receipt, restore the invoice balance, restore the customer balance, all in one transaction, all logged with the user and timestamp of the void.
Three things to verify when evaluating void handling:
AR automation is most valuable when it connects to the other parts of the distribution operation:
The integration matters because standalone accounting software handles AR in isolation. Customer balance in QuickBooks doesn't prevent a customer from placing an order on a separate ecommerce platform, or from getting items loaded onto a delivery truck by a warehouse team looking at a different screen. A distribution-fit ERP ties these together so the credit limit set by the controller actually blocks the order at entry time.
The distributors most frustrated with their AR process are usually running QuickBooks plus two or three spreadsheets plus a homegrown Access database. When they migrate to a real ERP, three pitfalls recur:
Underestimating open-balance migration. Your first day live on the new system, every open invoice from QuickBooks needs to land in the new system with the same balance, same terms, same aging. Miss this and your AR aging is wrong from day one. See ERP Migration Checklist for Wholesale Distributors for the full migration sequence.
Assuming the ERP's statement format will match the old one. Your customers are used to the QuickBooks statement format. Changing it abruptly generates confusion and AR inquiry calls. Most ERPs let you customize the statement layout — do that work during implementation, not after.
Forgetting to migrate customer email addresses. If you've been mailing statements for 10 years, half your customer records may not have an up-to-date email address for the AR contact. Gathering those in advance saves the first month of emailed statements from becoming a phone-call marathon.
Ask the Ledger includes all five capabilities listed above as core modules. Batch payment application runs atomically across the cash receipts, invoices, and customer tables in a single PostgreSQL transaction — Apply or Rollback, no half-applied checks. Customer statements generate in single-customer or batch mode with preview, print, and batch PDF output. The integrated email service sends invoices and statements via SMTP with OAuth 2.0 support for Gmail and Microsoft 365, and every email is logged to an `email_log` table for audit. Void handling reverses the full cascade (receipt + invoice balances + customer balance) in one transaction and preserves the voided record with a clear void marker.
Because the B2B customer portal shares the same PostgreSQL database as the desktop ERP (not a sync layer), statements a customer views in the portal reflect the same aging and balance data the AR clerk sees in the back office — updated in real time as payments post. For distributors moving off QuickBooks, that consolidation is usually the single biggest operational win.
For the broader financial context on moving to a distribution-fit ERP, see Distributor Accounting Software: How to Choose the Right One and How to Switch from QuickBooks to a Distribution ERP.