NetSuite, Acumatica, or QuickBooks: Adding Card and ACH to Your ERP

On this page 8 sections

1. Why Payments Outside Your ERP Create Reconciliation Headaches
2. ERP Payment Integration for Distributors: Native Modules vs. Third-Party Connectors
3. Automatic Level 2 and Level 3 Data for ERP Credit Card Processing
4. Auto Cash Application and Payment-to-Invoice Matching
5. Storing Buyer Cards Securely Inside the ERP
6. Questions to Ask Before Signing an ERP Payment Contract
7. Migrating Saved Cards When You Switch ERP Payment Providers
8. Next Steps

Key takeaways

• Judge ERP payment options on cash application, Level 3 data and token handling, not just the headline rate.
• Level 2 and Level 3 data only helps when it comes from real sales order fields and qualifies under current card network rules.
• Store gateway tokens in the ERP, never raw card numbers, and get stored-card consent in writing.
• Before you sign, make sure the contract lets you export or migrate saved card tokens if you leave.

Most distributors don't lose money on payments at the rate line. They lose it in three other places: hours spent matching deposits to invoices, commercial card transactions that miss enhanced data, and saved cards stranded with a provider you want to leave. This guide covers ERP payment integration for distributors running NetSuite, Acumatica or QuickBooks. It explains how native and third-party payment options differ, how Level 2 and Level 3 data and auto cash application should work, how to store buyer cards safely, and what to ask before you sign.

Why Payments Outside Your ERP Create Reconciliation Headaches

Picture a typical receivables day at a distributor:

• A purchasing manager calls in a card for three open invoices.
• A sales rep keys a card for a will-call order.
• An ACH payment arrives, with the remittance details in a separate email.
• A customer pays online through a link but short-pays one invoice over a damaged case.

If payments run on a standalone terminal or a separate portal, someone has to re-enter each of these in the ERP. That creates predictable problems:

• Mismatched deposits. Processors usually settle in batches, sometimes net of fees. One bank deposit can cover dozens of transactions across many customers.
• Unapplied cash. Payments without clear invoice references sit in suspense. Customers then appear past due and can land on credit hold by mistake.
• Double-entry errors. Transposed invoice numbers and wrong customer IDs throw off aging reports and statements.
• Lost enhanced data. A card keyed into a separate terminal carries none of the line-item detail already on your sales order.

Fixing these problems is the main reason to connect payments to the ERP. A slightly lower rate rarely makes up for an AR team that spends every morning reconciling.

ERP Payment Integration for Distributors: Native Modules vs. Third-Party Connectors

All three platforms offer some way to take payments inside the software. That might be a payment option sold by or through the ERP vendor, or a connector built by a gateway or integrator. Features, pricing and availability change, so treat what follows as a framework and confirm current details with your ERP partner.

NetSuite Payment Processing

NetSuite environments are often heavily customized, with custom transaction forms, fields and workflows. When you evaluate NetSuite payment processing options, confirm that the connector reads your actual sales order and invoice records, including custom fields. It should not assume a standard setup. If you run more than one entity, ask how the connector handles subsidiaries and multiple bank accounts.

Acumatica Payment Integration

Acumatica supports payment processing through plug-ins that link the ERP to a gateway. For any Acumatica payment integration, ask three things:

• Which gateways does the plug-in support?
• Does it handle both card and ACH?
• Does it pass line-item detail from the sales order, or only the invoice total?

QuickBooks Enterprise Payments

Intuit offers its own payment service for QuickBooks, and third-party processors can connect as well. If you're comparing QuickBooks Enterprise payments options, look at how each one posts deposits and fees, whether payments apply to the right invoices automatically, and how stored cards are handled. MannyPay lists QuickBooks among its integrations. Review MannyPay's QuickBooks integration and confirm which edition and workflows it covers for your setup.

Many ERP connectors route transactions through a gateway such as Authorize.net or NMI. If a connector you're considering supports one of these, a merchant account through MannyPay can sit behind it. See our payment gateway options for the gateways MannyPay works with.

Automatic Level 2 and Level 3 Data for ERP Credit Card Processing

Distributors see a lot of corporate, purchasing and fleet cards. Card networks can apply lower interchange to some commercial card transactions when the merchant passes enhanced data:

• Level 2 typically includes fields such as tax amount, customer code or PO number, and merchant postal code.
• Level 3 adds line-item detail: product codes, descriptions, quantities, units of measure, unit prices, line totals, freight and ship-to information.

Your ERP already stores most of this on the sales order. Good ERP credit card processing pulls those fields automatically when the payment is captured, so nobody has to retype them.

A few cautions apply:

• Data quality matters. Placeholder or dummy line items can disqualify a transaction and may draw network scrutiny. The data has to describe what you actually sold.
• Eligibility varies. Enhanced data helps only on qualifying commercial cards. The networks also revise their validation rules and rate tiers from time to time, so ask your processor what currently qualifies.
• Watch your pricing model. On flat-rate pricing, interchange savings may not reach you at all. Our guide to what wholesale distributors should pay in card fees explains why pricing structure matters.

If your ERP payments are embedded in software, also read our industry news coverage of recent card network fee changes for embedded payments and ask your provider how it applies to you.

Auto Cash Application and Payment-to-Invoice Matching

Cash application is where an integration earns its keep. Every payment should land on the right customer and the right invoices without manual work.

Check whether the integration can handle these distributor scenarios:

1. One payment, many invoices. A customer pays several open invoices in one transaction, and the system splits the amount correctly.
2. Partial and short payments. The system records a short pay against a specific invoice and flags the difference for review. It shouldn't force the payment into unapplied cash.
3. Credit memos. Open credits net against invoices before the charge.
4. Deposits and prepayments. Payments taken against a sales order before shipment carry over to the invoice.
5. Batch reconciliation. Settlement batches tie to the bank deposit. Processing fees post to the right GL account whether you settle gross or net.
6. ACH remittance. For B2B ACH, ask whether the integration supports corporate entry formats. The CTX format, for example, can carry remittance addenda that help with matching.

Illustrative example: A hardware supply customer owes three invoices and holds one credit memo. The buyer opens a payment link from your statement, selects all four items and pays the net amount by purchasing card. In a well-integrated setup, all three invoices close and the credit memo is consumed. Enhanced data passes for each line, and the payment appears in the right settlement batch. Nobody in AR has to touch it.

Payment links on emailed invoices and a self-service portal cut down on cards your team keys over the phone. For the phone orders that remain, a virtual terminal for keyed card payments can work alongside the ERP. Our explainer on taking card payments without hardware covers how virtual terminals work.

Storing Buyer Cards Securely Inside the ERP

Repeat buyers want you to keep their card on file, especially for standing orders and recurring replenishment. Storing that card the right way protects both you and the buyer.

• Store tokens, not card numbers. The gateway should replace the card number with a token, and only the token should live in the ERP. Raw card numbers in customer records, notes fields or spreadsheets expand your PCI DSS scope and your risk.
• Remember that tokens reduce scope but don't eliminate it. You still have PCI DSS obligations. Confirm your validation requirements with your processor.
• Get stored-credential consent. Card network rules expect you to obtain the cardholder's agreement to store and charge the card, and to flag merchant-initiated charges correctly. Your trade credit application or customer onboarding form is a natural place to capture this. Our guide to vetting buyers before offering net 30 terms covers what else that form should include.
• Limit who can charge. Use ERP roles so that only authorized staff can charge stored cards or change payment methods.
• Keep cards current. Cards expire and get reissued. Ask whether your gateway offers an account updater service. Our article on keeping stored cards current with an account updater explains how it works.

If you plan to pass card costs to buyers, a compliant surcharging program may be an option where state law and card network rules permit it. Rules differ by state and card brand. Confirm requirements with your processor and a qualified advisor.

Questions to Ask Before Signing an ERP Payment Contract

Use this checklist when you compare proposals:

• Pricing structure: Is pricing interchange-plus, tiered or flat? Are software, gateway and per-transaction fees listed separately?
• Level 3: Does the integration pass line-item data automatically from sales orders? Can I see a sample transaction?
• Cash application: How does it handle multi-invoice payments, short pays, credit memos and deposits?
• ACH: Does it support B2B ACH, remittance data and returns handling inside the ERP?
• Deposits and fees: Is settlement gross or net? How do fees post to the GL?
• Tokens: Who owns the stored card tokens? Can I export or migrate them if I leave?
• Term and exit: What is the contract length? Are there early termination or equipment fees?
• Support: Who do I call when a payment fails to post: the ERP partner, the connector developer or the processor?
• Upgrades: Does the connector stay compatible through ERP version upgrades?

Migrating Saved Cards When You Switch ERP Payment Providers

Tokens are usually specific to one gateway. If you change providers without a plan, your stored buyer cards may stop working. You would then have to collect new cards from every account, which frustrates buyers and delays collections.

To plan a clean migration:

1. Read your current contract for language on data ownership and token export.
2. Request a secure transfer. Card data generally moves directly between PCI DSS-compliant parties under an agreed process. You should never handle raw card numbers yourself.
3. Map old tokens to new ones so each customer record in the ERP points to the correct new token.
4. Run old and new in parallel for a short period. Test charges on a few accounts before you switch everyone.
5. Ask for a list of cards that failed to transfer, and contact only those buyers.

Next Steps

The right ERP payment setup reconciles itself, passes accurate enhanced data, and keeps buyer cards secure and portable. Start by listing the cash application scenarios that take up the most of your AR team's time. Then use the checklist above to compare proposals on more than rate.

MannyPay offers merchant accounts, payment gateways and integrations, including QuickBooks, Authorize.net and NMI. To review your current setup, request a free quote from MannyPay. A specialist will respond within one business day.

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.