Medicaid Billing: 837P, 837I & 835

Billing is where service delivery turns into revenue, and where small upstream errors become expensive. A claim built from unverified time, or referencing an authorization that had already been exhausted, will be denied — and the cost of a denial is not the claim value, it is the staff time to find it, understand it, correct it, and resubmit it inside the timely-filing window.

ArborSoft builds claims from data that has already been validated, and closes the loop by posting remittances automatically.

Generate 837P and 837I claims

ArborSoft produces both professional (837P) and institutional (837I) claim files in compliant X12 format. Claims assemble from posted service data, carrying the consumer, employer, rendering provider, service codes and modifiers, units, dates of service, and the authorization reference the payer expects.

Because the underlying service records were already checked against the authorization when they were captured, the claim starts from validated data rather than being validated for the first time at submission.

Scrub before submitting

Pre-submission scrubbing applies both structural X12 validation and payer-specific edits: eligibility for the date of service, service-code and modifier combinations the payer accepts, authorization reference and remaining units, date-span and units-per-day limits, and duplicate detection against previously submitted claims.

Claims that fail are held on a work queue with the specific failure identified. Fixing a claim before submission is a correction; fixing it after is a denial with a clock attached.

Post 835 remittances automatically

Imported 835 electronic remittance advice is matched to originating claims and posted line by line — paid amounts, contractual adjustments, patient responsibility, and denial reason codes.

Clean matches post without intervention. Anything ambiguous — a partial payment, an unmatched claim reference, an unexpected adjustment — routes for review rather than being force-posted into a balance that will have to be untangled later.

Work denials as a pattern, not one at a time

Denials are captured with their reason codes and grouped by payer, reason, service type, and program. That grouping is the point: twenty denials sharing one reason code usually mean one fixable upstream problem, not twenty individual corrections.

Claims can be corrected and resubmitted from the same workflow, with the resubmission linked to the original so the full history stays intact.

Reconcile and report

Billing reporting covers claim aging by payer and submission batch, adjudication status across the pipeline, reimbursement against expected amounts, denial rates by reason and payer, and outstanding receivables by program and funding source.

For grant-funded and program-reported work, the same data exports in the formats funders require, alongside the utilization reporting produced from authorization tracking.