Intelligent Document Processing Developer Job Description

An intelligent document processing (IDP) developer builds the software that turns incoming paper and PDFs into structured data a business system can trust. The inputs are scanned claim forms, invoices, bank statements, W-2s, medical bills, bills of lading and loan packages. The output is a JSON record or database row with every field named, typed, validated and traceable back to the spot on the page where it was found.

The job sits between machine learning and back-office operations. A working pipeline has five stages, and the developer owns all of them. Ingestion pulls files from email inboxes, SFTP drops, scanners and upload portals, then normalizes them: splitting multi-document PDFs, deskewing images, fixing rotation. Classification decides what each page is, such as a 1099 versus a pay stub, or page one of a policy application versus an addendum. Extraction reads the fields. Validation checks them against business rules and reference data: does the policy number exist, do the line items sum to the invoice total, is the date of loss before the date the claim was filed. Finally, low-confidence or rule-failing documents go to a human review queue, and corrected values flow back as training and test data.

The tooling is specific. On AWS, the Amazon Textract AnalyzeDocument API accepts feature types including TABLES, FORMS, QUERIES, SIGNATURES and LAYOUT, and the developer decides which to request for each document class. On Microsoft's side, Azure Document Intelligence lets a team train a custom classification model that identifies the document type before an extraction model runs, and Microsoft's documentation says five labeled examples of the same form are enough to get started on a custom extraction model. Enterprise shops also run packaged capture platforms such as Tungsten TotalAgility, ABBYY Vantage, Hyperscience and UiPath Document Understanding, and a developer may spend as much time configuring those as writing Python.

Large agencies show what a production stack looks like. The Department of Veterans Affairs' 2024 AI use case inventory describes a claims automation that combines optical character recognition, intelligent character recognition, natural language processing and robotic process automation, working on information extracted from documents that claimants submit.

What separates this role from a general automation developer is ownership of accuracy. An automation developer builds bots that move data between applications and treats the input as given. The IDP developer decides whether the data is right in the first place: designing the extraction schema with operations staff, setting per-field confidence thresholds, building labeled test sets, and reporting field-level precision and recall to the business owner. When a supplier changes its invoice layout and extraction quality for that supplier drops overnight, this is the person who gets the ticket.

Day to day, the developer works with claims or accounts-payable supervisors who define what "correct" means, data engineers who own the downstream warehouse, security and compliance staff who care where personal data is stored and for how long, and the review team that handles exceptions. The job includes plenty of unglamorous debugging: why dates from one source parse as day-month, why a checkbox reads as checked when it holds a stray pen mark, or why a fax-quality page fails OCR entirely.

The usual path runs through a bachelor's degree in data science, software engineering, computer science or an allied field. A degree is not the only route: capture administrators, RPA developers and data analysts who have run extraction projects in production also move into the role, provided they can write and test real code.

The core technical stack is Python for pipeline code and model work, with C# and .NET in shops built on Tungsten TotalAgility and other Windows-based capture platforms. Expect to use REST APIs, SQL, message queues and at least one cloud provider's document services. Image handling is part of the job too: deskewing, despeckling, binarization and page splitting with libraries such as OpenCV and pdfplumber, plus a working knowledge of PDF internals so you can tell a text-layer PDF from a scanned image wrapped in a PDF. On the model side, you need to know how to build a labeled dataset, split it properly, and read precision, recall and confusion matrices per field. Prompting large language models for structured output, validating that output against a JSON schema, and writing regression tests for prompts belong in the same toolkit.

Domain knowledge separates a strong candidate from a generic one. An insurance pipeline means ACORD forms and first notice of loss packets. Mortgage work means the Uniform Residential Loan Application, pay stubs, W-2s and bank statements. Healthcare payers process CMS-1500 and UB-04 claim forms. Knowing which fields a downstream adjuster or underwriter actually uses lets you design a smaller, more accurate schema.

Vendor history matters on resumes. Kofax, a long-time document capture vendor, renamed itself Tungsten Automation on January 16, 2024, so experience listed under the Kofax name and the Tungsten name refers to the same company's platforms.

As a rough guide, people reach this role after 2 to 5 years in software development, RPA development or data engineering, ideally with at least one extraction pipeline they shipped and supported.

No license or certification is required. Optional credentials include the UiPath Certified Professional Automation Developer Associate, awarded by UiPath, for teams that build on Document Understanding; the AWS Certified Machine Learning Engineer - Associate, awarded by Amazon Web Services, for teams that build on AWS; and AIIM's Certified Information Professional (CIP), whose body of knowledge includes "extracting intelligence from information." Check the issuer's page before you study: Microsoft's page for the Microsoft Certified: Azure AI Engineer Associate now states that the certification and its renewal assessment are retired.

Soft skills are concrete here. You will sit with claims processors to watch how they read a document, translate their judgment calls into rules, and explain to a manager why an accuracy gain on one form type is worth a sprint. Clear written documentation of each schema and threshold decision spares the next developer from reverse-engineering them.

BLS does not count intelligent document processing developers as a separate occupation, so the closest public numbers come from its industry-level software developer data. In May 2025, BLS counted 43,010 software developers working for insurance carriers, at a median wage of $130,840, and 515,410 in computer systems design and related services, the consulting and integration industry, at a median of $132,050. Those figures cover all software developers in each industry, not only document specialists, but they show where the employers who buy and build extraction pipelines sit.

Government is a useful window into why this work matters. In a July 2026 report on the 2026 filing season, GAO said the IRS uses two systems to either manually transcribe or digitally scan paper returns into an electronically readable format. According to IRS officials quoted by GAO, the individual paper processing system was unable to process tax year 2025 returns for the first 6 weeks of 2026, and the scanning system for business paper returns was unable to process them for the entire 2026 filing season. The IRS responded by sending more inventory than planned to the outside vendors it uses to scan paper returns, as part of its long-term digitalization strategy. An earlier GAO report, from March 2026, describes what those vendors do: they scan the returns using software that extracts the information and transmits it to the IRS in the same format as an e-filed return. That is an IDP pipeline in a single sentence, and someone has to build and maintain it.

The Department of Veterans Affairs offers a similar picture from the benefits side. Its AI strategy says some workflows, such as disability claims processing, already use optical character recognition and natural language processing to extract information from documents, but that across the VA the majority of operational workflows remain manual, multi-step and time-intensive.

Tool churn is part of the career. Amazon's Textract documentation says Amazon Augmented AI, the service Textract uses to run the human review workflows a developer configures, entered maintenance mode in July 2026 and no longer accepts new customers; requests from accounts that are not existing customers fail. A developer starting a new Textract pipeline on an account that is not already an Augmented AI customer has to route low-confidence documents to reviewers some other way, whether a custom queue, a capture platform's validation station or a workflow tool. Platform renames, API version changes and model retirements all force rework, and a developer who keeps regression test sets can measure exactly what each one changed.

Career paths branch in three directions. Some developers move toward architecture, owning the document strategy for a whole claims or lending operation and choosing between cloud services and packaged platforms. Some move into machine learning engineering, focusing on custom models for handwriting, tables or low-quality scans. Others move into product or operations leadership, running the intake function that the pipeline feeds. In each case, bring evidence: measured accuracy on real production documents, before and after your changes, and the share of documents your pipeline moved without manual keying.

The work also travels well across industries. The same skills that extract fields from an insurance claim apply to a customs declaration, a lab requisition or a court filing, so a developer is not locked into one sector.

Dear Hiring Manager,

I am applying for the Intelligent Document Processing Developer position on your claims technology team. For the past four years I have built and run document extraction pipelines at a regional property and casualty insurer, and I would like to bring that work to a larger operation.

My main project was the first notice of loss intake pipeline. Adjusters were keying fields from emailed PDFs, phone photos of police reports and scanned ACORD forms. I designed the extraction schema with two claims supervisors, built a page classifier to separate the document types inside each submission, and wrote the extraction layer using a cloud OCR service for printed forms and a large language model with a strict JSON schema for free-text narratives. Every field carries a confidence score, and anything below its threshold lands in a review queue I built with our operations team. Their corrections feed a labeled test set that runs on every release, so a model or prompt change cannot ship if it lowers field accuracy on any document type.

I am most proud of the dull parts. I wrote the validation rules that catch a date of loss after the report date, a policy number that does not exist, or a vehicle identification number with a bad check digit. I also documented each threshold decision so that the supervisors understand why a document went to review.

Your posting mentions a migration from an older capture platform to cloud services. I led a smaller version of that move last year, running both systems in parallel against the same document set until the new pipeline matched the old one field by field.

I would welcome the chance to walk through my test harness and review queue design with your team.

Sincerely, Jordan Ellis