Medical billing services — companies that handle claims and collections for physician practices — are a genuinely good fit for Acumatica on the accounting side, and a genuinely bad fit if anyone expects it to process claims. Worth separating those two clearly, because a medical billing company's own internal operations often get conflated with the claims-processing pipeline it runs for clients.
The billing service's books versus the claims it processes
A medical billing company has its own revenue (fees charged to physician-practice clients, often a percentage of collections) and its own AP, payroll, and financial reporting — completely ordinary ERP territory, and Acumatica handles it well, including the percentage-of-collections billing model via recurring or usage-based invoicing patterns. Separately, the company operates a claims clearinghouse workflow — submitting claims to payers, tracking adjudication, posting remittances — for its clients' patient billing. That second workflow is specialized healthcare claims software territory (clearinghouse integration, ANSI X12 837/835 transaction handling); Acumatica has no native claims-clearinghouse capability and should not be asked to grow one.
Where the two systems meet: revenue recognition on collections
The integration point that actually matters for the billing company's own books is: when the claims system reports that a client practice collected a payment, the billing company's percentage fee becomes billable revenue. That is a legitimate, scoped integration — a summary feed, not a claims feed.
POST /entity/Default/24.200.001/Invoice HTTP/1.1
Content-Type: application/json
{
"CustomerID": { "value": "PRACTICE-014" },
"Description": { "value": "Billing service fee — June collections" },
"Details": [
{ "InventoryID": { "value": "BILLSVC-FEE" },
"Qty": { "value": 1 },
"UnitPrice": { "value": 4128.60 },
"Description": { "value": "6% of $68,810.00 collected — June 2026" } }
]
}
The collected amount and the fee percentage cross the boundary; the underlying claim detail, diagnosis codes, and patient identity stay in the claims system.
Do not build patient-level AR for the practice's patients in Acumatica
The recurring bad idea in this vertical is using Acumatica to track each physician practice's individual patient AR balances, on the theory that "it's all AR, why not one system." That reintroduces the PHI-in-the-ERP problem covered in the HIPAA piece in this series, at scale, across every client practice the billing company serves — a much larger blast radius than a single provider's own patient list. Keep patient-level AR in the claims/practice management system; Acumatica tracks the billing company's own receivable from its physician-practice clients, which is one AR line per practice per period, not one per patient.
Larger medical billing services run regional offices or client-facing teams as separate cost centers. Acumatica's branch structure fits that cleanly — branch-level P&L for each regional team while consolidating at the company level — which is ordinary multi-branch ERP work, no healthcare specifics involved.
Wrapping up
For a medical billing company's own financial operations — fee revenue, AP, multi-branch consolidation — Acumatica is a solid, unremarkable fit. Keep it there: do not let patient-level claims or AR detail migrate into the ERP, and treat the claims-processing pipeline as a separate, specialized system that feeds Acumatica only a periodic revenue summary.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.