Yes, but “works for both” means different things depending on whether the two revenue streams share a record or just share a login.
Most DME suppliers run three payment paths simultaneously: assigned insurance claims, patient responsibility after adjudication, and straight retail cash sales. A shower stool sold off the showroom floor doesn’t touch a payer. A CPAP does. A brace might go either way depending on whether the patient’s coverage holds. If those flows sit in separate systems (or in the same system with separate item masters) you reconcile forever, and you find out about the mismatch at month-end.
What “both” actually requires
One item master, two price paths
The same HCPCS-coded item needs a DMEPOS fee schedule rate for insurance and a retail price for cash. Not two catalog entries.
One inventory record
A serialized asset sold retail and a serialized asset delivered on a capped rental draw from the same stock. If inventory lives apart from billing, you’ll sell equipment you’ve already committed to a rental.
Point-of-sale plus claim submission
Card capture at the counter and 837 submission to a DME MAC, from one platform.
Patient responsibility handled as billing, not retail
Deductible, coinsurance, and post-adjudication balances aren’t cash sales. They’re the tail end of a claim, and they belong in your revenue cycle workflow with the same aging and follow-up.
Where suppliers get it wrong
The failure mode isn’t technical. It’s the ABN.
When Medicare usually covers an item but may not in a specific case, DMEPOS suppliers must issue an Advance Beneficiary Notice of Noncoverage (Form CMS-R-131) before furnishing the item in order to transfer financial liability to the patient (CMS, FFS ABN). No valid ABN, no ability to bill the patient. The claim goes out with a GA modifier if one is on file. Without it, a denial becomes a write-off.
That’s the actual retail/insurance boundary, and it’s a documentation problem before it’s a payments problem. A system that treats “cash sale” as simply not a claim will let staff ring up an item at the counter that Medicare would have covered, or collect from a patient for a denied item with no signed ABN behind it. CMS also updated the ABN form; if your templates still reference the prior version, replace them.
What to ask a vendor
Ask them to walk through one scenario end to end: a patient walks in, wants an item, coverage is uncertain. Where does the ABN get captured? What modifier does the claim carry? If Medicare denies, how does the balance move to patient responsibility, and does it enter the same denial workflow as everything else?
A platform that can answer that handles both. A platform that shows you a POS module and a claims module in separate demos handles neither — it handles two things and leaves the seam to you.