I get asked "is Acumatica HIPAA compliant?" often enough that it deserves a straight, careful answer rather than a marketing one. The short version: HIPAA compliance is a property of a covered entity's or business associate's whole program — policies, training, risk assessment, hosting arrangement, and configuration — not a certification a software vendor hands you in a box. Acumatica is not a certified EHR and does not claim HIPAA certification as a product; what it offers is a set of general security controls that can be configured as part of a compliant program, provided everything around them is also done right.
What HIPAA's technical safeguards actually ask for
The HIPAA Security Rule's technical safeguards boil down to a short list: access control (unique user IDs, role-based restriction, automatic logoff), audit controls (recording activity on systems containing PHI), integrity controls (protecting data from improper alteration), and transmission security (encrypting PHI in transit). None of these are exotic — they are standard enterprise security practice — but each one has to actually be configured and evidenced, not assumed.
What Acumatica genuinely provides toward that list
- Access control. Unique logins, role-based access control down to screen and field level, and configurable session timeout / automatic logoff settings.
- Audit controls. A configurable audit trail that can be turned on per screen and per field, logging create/update/delete activity with user and timestamp, plus login/logout and access history.
- Field-level encryption. AES-256 encryption is available for designated sensitive fields (Acumatica ships this for things like payment card and SSN-style fields, and administrators can extend it to other fields), and standard TLS covers transmission security for data in transit.
These are real, verifiable features — not something I am inferring. They are also generic security controls that any well-built enterprise system would have, not a HIPAA-specific certification layer.
Acumatica does not include a Business Associate Agreement as a standard offering the way some healthcare-specific SaaS platforms do — if PHI will genuinely reside in your Acumatica instance, you need to work through Acumatica (or your cloud hosting provider, if self-hosted) on a BAA and confirm the specific deployment and hosting arrangement supports it. It also has no PHI-aware data classification, no built-in minimum-necessary access review workflow, and no HIPAA-specific breach notification tooling. Those are program-level controls you build around the ERP, not features you turn on inside it.
The question that actually matters: should PHI be in Acumatica at all?
In most of the architectures I have built across this vertical series, the better answer is to keep PHI out of Acumatica entirely. Clinical and patient-identifiable data lives in the EHR, practice management system, or lab information system that is purpose-built and typically already covered by its vendor's BAA program. Acumatica receives de-identified financial summaries — billed amounts, service dates without diagnosis detail, aggregate supply consumption — across the integration boundary. That design sidesteps most of the HIPAA scoping question for the ERP rather than trying to answer it.
If a specific requirement genuinely forces patient-identifiable data into Acumatica (patient-level AR aging for a collections team is the most common real case), treat it as a deliberate, documented decision: enable field-level encryption on the relevant fields, restrict the role that can see them, turn on audit trail for those screens, and get the BAA question answered in writing before go-live — not after an auditor asks.
Wrapping up
Acumatica is not HIPAA-certified and is not an EHR. It has real, usable security controls — RBAC, audit trail, field-level encryption, TLS in transit — that are legitimate components of a compliant deployment. Whether an actual deployment is HIPAA compliant depends on configuration, hosting, BAAs, and the surrounding program, not on the software alone, and the simplest way to reduce that burden is to keep PHI out of the ERP wherever the architecture allows it.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.