Claims intake automation means software receives claims from mail scans, fax, portal uploads and email, recognizes which pages are claims, separates them from attachments and other paper, links each attachment to its claim, and drops each claim into the right work queue. People handle the pages the software cannot place with confidence, before anyone keys a claim.
Where do claims arrive before claims intake automation?
Before claims intake automation, claims arrive through four channels: paper mail, fax, a portal or upload page, and email. Each channel lands in a different place, with its own format and its own person checking it. The first job of intake automation is to pull all four into one inbox where every page is handled the same way.
Paper mail is the oldest channel and the slowest. Envelopes hold claim forms, explanations of benefits (EOBs), letters and records together. Someone opens them, date-stamps the contents and scans them, usually in batches at set times of day. The post on paper claims processing follows that path in detail.
Fax is the channel with the worst image quality. A faxed claim form may be skewed, cropped or low resolution, and several documents often arrive in one transmission. Many offices receive faxes as image files in an electronic fax inbox, which makes them easy to feed to software but hard to read by eye at volume. Sorting a fax inbox has its own guide, the post on triaging a clinic fax inbox.
Portal uploads and email bring files that are already digital. They can be clean PDFs from billing software, phone photos of a form, or a single PDF holding a claim and twenty pages of records. The file name and sender help, but they rarely say what is inside.
A useful first step, before buying anything, is a one-week count. Record how many pages arrive through each channel, and what share of them are claims. The count tells you where intake automation will pay off first and which channel can wait.
Claims intake automation for sorting and classifying documents
Claims intake automation for sorting and classifying documents means software labels each page or file by document type: claim form, EOB, denial letter, medical record, attachment or other. It uses the page's layout and text to decide, and it gives each label a confidence. Pages it cannot label with confidence go to a person instead of a queue.
Claim forms are among the easier documents to recognize because their layout is fixed. A CMS-1500 has a numbered grid with item 24 service lines across the lower half. A UB-04 has numbered form locators and a revenue code table. A classifier that has seen both can tell them apart from an EOB, whose layout varies by payer, or from a letter, which is mostly prose.
The harder cases are the ones in between. A primary payer's EOB stapled behind a secondary claim is an attachment, not a stray EOB for payment posting. A records excerpt sent with a claim is supporting documentation, not a records request. Getting these right needs more than the page's own layout: it needs to know what came before it in the same file.
A good label set is short. Most offices need claim form (professional), claim form (institutional), EOB, claim attachment, payer letter, records and other. Every label should map to a team or queue. A label nobody acts on only adds work. How a classifier tells fax documents apart, and how to define labels for a fax line, is covered in the guide to inbound fax classification.
When a machine learning model does this classification, it can be wrong in quiet ways, labelling a page with high confidence and the wrong type. The post on artificial intelligence claims processing explains what those models do with a claim and where they need a person.
How should claim attachments and supporting documents be split and linked?
Claim attachments and supporting documents should be split from the claim form at their first page and linked to the claim by an identifier the claim itself carries, such as the patient account number or an attachment control number. The link must survive every later step, so an attachment is never sent, stored or reviewed apart from its claim.
Attachments arrive for set reasons. The CMS-1500 chapter of the Medicare Claims Processing Manual says an unlisted or not otherwise classified procedure code needs a narrative in item 19 or an attachment. It also says a paper claim for Medicare secondary payment must include a copy of the primary payer's EOB. The NUCC 1500 Reference Instruction Manual lists report type codes for attachments named in item 19, such as OB for an operative note, LA for laboratory results and EB for an explanation of benefits.
Splitting starts with finding boundaries. A new claim form starts a new claim. A page that does not look like a claim form, following a claim form, is probably an attachment to it. Separator sheets, page counts printed on the form, and a change of patient name all help. The edge case is two claims for the same patient back to back, each with attachments: the second claim form is the only boundary.
Linking is where intake automation earns its keep. For electronic claims, chapter 24 of the Medicare Claims Processing Manual describes the PWK segment as the "electronic staple" that connects paper documentation to an electronic claim. The claim carries an attachment control number of the submitter's choosing, and the documentation is sent with a matching cover sheet. An intake system should store that same control number with the attachment, so the two can be matched later.
As an example, a fictional faxed packet of nine pages holds a CMS-1500 for patient Ana Torres (account number EX-44817, an example value), two pages of an operative note, a CMS-1500 for a second patient, and five pages of a primary payer EOB. Intake splits it into two claims. The operative note is linked to the first claim by position and patient name. The EOB is linked to the second claim by the patient name and member ID printed on both.
When a link is uncertain, the attachment waits in a review queue with both candidate claims shown. Guessing wrong sends one patient's records with another patient's claim.
Claims intake queues and routing rules
Claims intake queues and routing rules decide where each sorted document goes next: which team, which work queue and in what order. Rules usually route by document type, payer, claim type and urgency. A claim with missing attachments or a doubtful label goes to a review queue rather than a work queue.
Start with document type. Professional claims go to the professional billing queue, institutional claims to the facility queue, EOBs to payment posting, payer letters to denials or correspondence. That single rule handles most of the volume.
Add payer next, when teams are split by payer. A Medicare claim and a commercial claim may go to different people because their rules differ. The payer name and address on the claim form are usually enough to route on.
Then add urgency. A claim close to the payer's filing limit, a corrected claim answering a rejection, or a claim marked as a resubmission should jump the queue. Dates of service and the claim's frequency or resubmission code are the fields that drive this.
Finally, add exception rules. A claim with no attachment where one is expected, a claim whose pages do not match its page count, or a file the classifier could not label at all goes to a person. Exception rules keep uncertain work visible instead of letting it sit in the wrong queue.
Rules run in order, and the order matters. Put exception rules first, so a doubtful page never reaches a work queue on the strength of a later rule. Put urgency next, then payer, then document type. Write each rule down with its owner, and review the rule list when a team changes. A rule nobody remembers writing is the usual reason claims start landing in an empty queue.
Track one number per queue: how many items arrived and how many were moved by hand to another queue. A high move count means a rule is wrong or missing. That count is also the evidence you need before adding a new rule, rather than adding rules on a hunch.
Once a claim reaches its queue, the next step is reading its fields. That work, from scan to structured fields, is covered in the guide to claims data extraction steps from scan to structured fields. Schema Care sits at that point rather than at sorting: it reads claim form fields and diagnosis and procedure codes, scores each value, and hands low-confidence ones to a reviewer, as the document types on the homepage list.
Claims intake automation for low-volume offices
Claims intake automation for low-volume offices is often not worth setting up yet. If a person can open, sort and route the day's claims in under an hour, software adds setup, tuning and review work without saving much. A low-volume office gains more from a clear manual routine and a single scanned inbox.
Signs that automation can wait include a single intake channel, a handful of claims a day, one person who handles all of them, and few attachments. In that office, the rules above can live in a one-page checklist that the person follows by hand.
Signs that it is time include a backlog that grows every week, claims routed to the wrong team, attachments separated from their claims, and staff spending more time sorting than keying. Any one of these suggests the manual routine has run out.
There is a middle step. Scan everything into one shared folder, name files by date and channel, and keep a simple log of what was routed where. That routine produces the counts and examples you will need later to set up automation, and it costs nothing.
The checklist below phases intake automation for an office that is ready to start.
| Phase | What to set up | Done when |
|---|---|---|
| 1. Channels | One inbox for mail scans, fax, uploads and email | Every page lands in the same place with its arrival date and channel |
| 2. Document types | A short label set mapped to teams | Each label has an owner and a queue |
| 3. Split rules | Boundary rules for claims and attachments | Multi-claim packets split correctly on a sample week |
| 4. Routing rules | Type, payer and urgency rules | Claims reach the right queue without a person moving them |
| 5. Review | A queue for low-confidence labels and links | A person sees every uncertain page within a day |
After intake, the rest of the claim workflow can be automated in phases too. The plan in claims processing automation picks up where intake ends.