Direct-to-patient specialty pharmacy is one of the more operationally complex healthcare models to run on a financial system. You have prescription transactions coming out of a pharmacy management platform, patient payments running through a healthcare payment processor, sales tax calculations spanning multiple product categories and state nexus rules, and a bank reconciliation process that depends on daily file imports. When any one of those pieces isn’t talking to NetSuite cleanly, the finance team absorbs the gap — manually.

A growing pharmacy platform came to us with a specific ask: get their payment processor, Cliq, reconciling reliably against NetSuite. What that conversation revealed was a broader picture. Four separate data flows were either broken, partially configured, or producing records that required manual cleanup before they could be used. We ended up rebuilding all four.

Scope Delivered

• Cliq Payment Processor — NetSuite Integration
• MindCloud + DRX Pharmacy Data Pipeline
• Avalara Tax Compliance via Magento
• BAI2 Bank Feed via SFTP

> Cliq Payment Processor — NetSuite Integration

October 2024 — March 2025

The client processes patient payments through Cliq, a payment processor built for healthcare commerce. The problem was visible at month-end: completed transactions in Cliq weren’t landing in NetSuite in a way that made reconciliation possible. Order IDs weren’t mapping to NetSuite’s internal transaction identifiers, and payment confirmation data was arriving without the context needed to match it to an open invoice.

The reconciliation gap wasn’t just a reporting inconvenience. At month close, the AR ledger and actual cash receipts were being manually reconciled — a process that grew more error-prone as transaction volume scaled.

Cliq was transmitting payment records over SFTP without a consistent order ID schema that matched NetSuite’s transaction identifiers. The connection existed but it was producing unstructured data that required human intervention to process.

We rebuilt the integration at the field-mapping level, establishing a reliable SFTP handoff from Cliq with order IDs normalized to NetSuite’s internal transaction reference format. A SuiteScript was written to receive incoming payment files, validate the identifier match, and auto-apply the payment to the corresponding open invoice. Records that failed validation were routed to a review queue rather than silently dropped.

The final configuration was run through a full cutover test against historical Cliq transactions before going live — a deliberate step to confirm that back-dated reconciliation was clean before the team closed any reporting periods.

What changed: The AR team went from manually matching payments to working an exceptions queue. Month-end cash reconciliation stopped being a time-intensive manual process and became a review of flagged outliers.

> MindCloud + DRX Pharmacy Data Pipeline

October 2024 — March 2025

The client operates on DRX, a pharmacy management system purpose-built for direct-to-patient dispensing. DRX owns the prescription and inventory data. None of it was surfacing in NetSuite in a usable form.

Sales orders were either absent from the ERP entirely or arriving in a state that required significant cleanup before they could be processed. Inventory adjustments tied to dispensing events were landing as unposted entries — or not landing at all. The root of it was in the middleware: MindCloud, an iPaaS connector sitting between DRX and NetSuite, had never been fully configured to handle the specific data tables the client needed.

The DRX schema includes custom fields tied to formulary, dispensing status, and patient-level records that don’t have direct equivalents in a standard NetSuite sales order. MindCloud is capable of handling that complexity — but only if the mapping work has actually been done.

DRX was generating fulfilled prescription records that MindCloud wasn’t routing to the correct NetSuite transaction types. Inventory adjustments tied to dispensing events were landing as unposted entries — or not landing at all.

We worked through the MindCloud configuration layer to establish field-level mappings between DRX’s dispensing tables and NetSuite’s item fulfillment and inventory adjustment records. Each DRX transaction type was mapped explicitly:

• New fills route to a NetSuite sales order and item fulfillment with the correct posting behavior
• Refills follow the same path with the appropriate item reference
• Returns post as inventory adjustments with the correct GL impact

Inventory on-hand quantities are now adjusted at the point of dispensing, not retroactively during a manual count. Sales order processing through MindCloud handles the full DRX order lifecycle — from prescription receipt through fulfillment confirmation — with NetSuite as the financial record of what was dispensed, when, and at what cost.

> Avalara Tax Compliance via Magento

October 2024 — February 2025

The client sells through Magento, with Avalara handling sales tax calculation and remittance across multiple states. For a pharmacy operating under economic nexus rules that vary by state — and handling both taxable and tax-exempt medication categories — the configuration stakes are high. An incorrectly mapped product type in Avalara doesn’t just create a reporting discrepancy. It creates a compliance exposure.

When we came in, the Magento-Avalara connection was technically live but functionally incomplete. Tax categories weren’t mapped to Avalara’s correct AvaTax item codes for pharmaceutical products. Exemption certificates for qualifying orders weren’t flowing through the integration correctly. And a state tax authority audit added urgency: the configuration needed to be corrected and documented, not just operationally fixed.

Product tax categories in Magento were remapped to the correct Avalara AvaTax codes for prescription and OTC items. Exemption certificate handling was rebuilt to pass the correct exemption reason codes with each qualifying transaction — ensuring those records were audit-ready, not just functionally operational.

We also resolved a duplicated Funding Power of Attorney record in the Avalara production environment that had been creating account-level conflicts. Once that was cleared, the integration ran cleanly end to end.

The engagement closed with a working Magento-to-Avalara-to-NetSuite tax data flow and a full documentation package covering the integration architecture, the tax category mapping logic, and the exemption handling rules — so the configuration is maintainable without requiring our ongoing involvement for routine tax questions.

> BAI2 Bank Feed via SFTP

November 2025

Automated bank reconciliation in NetSuite depends on a reliable feed of bank transaction data in a format the system can parse. The client’s regional banking partner delivers transaction data in the BAI2 format — a structured file standard used by financial institutions for cash reporting. The file arrives over SFTP and needs to land in NetSuite’s bank reconciliation module cleanly.

The SFTP configuration wasn’t staging the BAI2 file in a location or format that NetSuite’s import process could reliably consume. Files were arriving but not processing, which meant the bank reconciliation was being done manually against exported statements rather than against a live feed.

We corrected the SFTP credential configuration, aligned the file path to NetSuite’s expected import directory, and wrote a SuiteScript import handler to process incoming BAI2 files on a scheduled basis. The handler parses the file, creates the corresponding bank transaction records in NetSuite, and flags any transactions that fall outside the expected format for manual review. Clean files process automatically. Problem files get surfaced, not swallowed.

With the feed running, the bank reconciliation process now operates against a daily import rather than manually exported statements. The reconciliation team works from a match queue rather than a spreadsheet comparison — and the monthly close process for cash accounts shortened considerably as a result.

What Stays With Us From This Engagement

The pattern here isn’t unique to pharmacy. It shows up in any NetSuite environment where multiple systems are expected to produce a single financial record — and the connections between them were never fully built.

Cliq had an SFTP connection. MindCloud had a connector license. Avalara had an active account. The BAI2 feed was technically enabled. None of them were doing what they were supposed to do because the configuration work — field mapping, file format alignment, certificate handling, scheduled imports — hadn’t been completed. That gap is invisible until month-end, and then it’s very visible.

This client now runs a connected financial system. Pharmacy data, payment data, tax data, and bank data all arrive in NetSuite without manual intervention. For a direct-to-patient pharmacy scaling transaction volume, that’s not a nice-to-have. It’s the foundation the rest of the operation is built on.

The engagement started with a payment processor that wasn’t reconciling. It expanded because each working integration made the next gap easier to see.

Engagement Repeatability

We delivered this as a reusable pattern for healthcare commerce organizations running NetSuite with multiple third-party systems. The same approach applies wherever:

• A payment processor delivers files over SFTP and those files need to auto-apply against open invoices
• An iPaaS connector (MindCloud, Celigo, Dell Boomi) is licensed and partially deployed but never fully mapped to the correct NetSuite transaction types
• Avalara is live but configured for a generic product catalog rather than the actual tax categories the business operates in
• BAI2 or OFX bank feeds are available from the banking partner but not running inside NetSuite’s reconciliation module

If any part of this looks familiar, we’d welcome a conversation.

We are a financial systems integration firm specializing in NetSuite ERP for healthcare, life sciences, and high-growth businesses.

📩 [email protected] ·  🌐 saloraerp.com ·  📞 +1·720·254·1320