Blog
Artificio automates claims-adjacent paperwork for healthcare payers using AI agents to classify, extract, and validate data without templates, posting seamlessly to SAP and Oracle with strict PHI controls.
A regional health plan in the Midwest runs a shared mailbox called "Claims Support." On a normal Tuesday it receives about 3,800 items. Roughly 400 of those are actual claims, and those flow into the claims platform without a human touching them. The other 3,400 are the problem. Provider dispute letters. Coordination of benefits questionnaires that members filled out by hand and photographed with a phone. Subrogation lien notices from personal injury attorneys. Overpayment recovery packets from a vendor. Credentialing attestations. Itemized bills that a provider sent as a 60-page PDF because someone asked for supporting documentation on a single line item.
None of those are claims. All of them touch claims. And every single one has to be read by a person before anything else can happen.
The plan has eleven people whose entire job is opening that mailbox, figuring out what each document actually is, pulling out four or five key fields, and re-keying those fields into either the claims system, the appeals tracker, or the ERP. Two of them do nothing but retype dollar amounts and invoice numbers into Oracle so that recovery vendors and independent review organizations get paid on time. When one of them is out sick, the backlog builds at about 300 documents a day and takes two weeks to clear.
This is the part of payer operations that almost never shows up in a digital transformation roadmap. The claims engine gets modernized. The member portal gets rebuilt. The paperwork surrounding claims stays exactly where it was in 2009, held together by shared mailboxes, Excel logs, and institutional memory.
The term sounds vague, so it helps to be concrete. Claims-adjacent documents are everything that arrives because a claim exists, but that a claims adjudication platform cannot ingest on its own.
Provider disputes and appeals arrive as letters on clinic letterhead, sometimes with a completed dispute form, sometimes without. They reference claim numbers that may be transposed, member IDs that may be a subscriber ID instead, and dates of service that may cover a range rather than a single day. The reason for the dispute is written in prose, not in a code.
Coordination of benefits questionnaires come back from members with handwriting, checkboxes, and occasionally a note in the margin explaining that the other insurance ended three months ago. Getting COB wrong costs real money, and getting it wrong in the member's favor costs money that is very hard to recover.
Itemized bills and medical records show up in response to documentation requests. These are the long ones. A 200-page record set where the only thing anyone needs is the operative note date and the CPT codes billed on that date.
Subrogation and lien correspondence arrives from law firms and third-party recovery vendors. Each firm has its own letter format. The plan needs the accident date, the member, the claimed amount, and the case reference, and it needs those pulled into the recovery workflow before statutory deadlines run out.
Provider roster and credentialing packets carry demographic changes, NPI numbers, license expirations, and W-9s. A stale roster produces directory inaccuracies, and directory inaccuracies now carry regulatory exposure in several states.
Vendor and third-party administrator invoices are the ones that end up in the ERP. Independent review organizations, repricing vendors, care management vendors, and recovery firms all invoice for work tied to specific claims or specific members. Those invoices need to be coded to the right cost center, matched against a contract rate, and posted for payment.
Enrollment and eligibility exceptions round it out. Retroactive terminations, newborn additions, and employer group changes arrive as spreadsheets, faxes, and email attachments that do not match any standard file layout.
Each of these categories has its own downstream system. Very few of them share a format. All of them contain protected health information.
Most payers have already tried to fix this at least once. The attempts usually fall into three buckets, and all three run into the same wall.
The first attempt is template-based OCR. Someone buys a capture product, builds zonal templates for the top five document types, and gets a decent hit rate on those five. Then the sixth type arrives, and the seventh, and the plan discovers that its document population has a long tail measured in hundreds of variants. Provider dispute letters alone might have 90 distinct layouts because every clinic writes its own. Building a template per layout is a permanent staffing commitment, not a project.
The second attempt is an EDI-first strategy. If everything came in as an 837, 835, or 275, none of this would be a problem. The trouble is that claims-adjacent documents are precisely the ones that do not have a clean transaction set, or that come from senders too small to support one. A solo practice appealing a denial is going to fax a letter.
The third attempt is offshore keying. This scales, and it is genuinely cheaper per document than domestic staffing, but it does not remove the two-day turnaround, it does not remove the error rate on handwritten fields, and it widens the PHI footprint in a way that compliance teams increasingly push back on.
The common failure is that all three approaches treat the document as a form to be read rather than as a case to be understood. A provider dispute letter is not a set of boxes. It is a paragraph that says a claim was underpaid, and somewhere in that paragraph are the claim number, the disputed amount, and the reason. Reading it requires comprehension, not coordinate lookup.
The shift that makes this tractable is moving from template matching to model-driven reading. Instead of asking "what is at position X on page 2," the system asks "what kind of document is this, and what does it say."
Artificio approaches this with AI agents that handle classification, extraction, and validation as connected steps rather than as separate products bolted together.
Classification comes first, and it does more work than people expect. The agent reads the document and decides what it is, which sender it came from, and which workflow owns it. A 60-page PDF that contains a cover letter, a dispute form, and an itemized bill gets split into three logical documents, each routed separately. Splitting alone removes a large chunk of manual handling, because mixed-content packets are the single most annoying thing in a payer mailroom.
Extraction then pulls the fields that matter for that specific document type. A dispute letter yields claim number, member ID, provider NPI, date of service, disputed amount, and dispute reason. A subrogation letter yields accident date, attorney firm, case number, and asserted lien amount. A vendor invoice yields invoice number, PO reference, service period, amount, tax, and the claim or member references in the line detail. The agent does not need a template for each sender because it is reading meaning, not position.
Validation is where the value gets locked in. An extracted claim number is checked against the claims system to confirm it exists and belongs to the named member. A member ID that fails lookup triggers a fuzzy match against name and date of birth. A vendor invoice amount is compared against the contracted rate for that service. Dates are checked for plausibility. Anything that fails validation is flagged before it reaches a human, so the human sees a specific problem rather than a blank form.
Confidence scoring runs through all three steps. High-confidence documents post automatically. Low-confidence ones route to review with the uncertain field highlighted and the source page shown alongside. Most plans start with a conservative threshold and raise it over the first quarter as they build trust in the numbers.
Any vendor can put a HIPAA badge on a website. What matters for a payer is whether the processing architecture actually holds up to a security review, because the plan carries the breach liability regardless of who wrote the code.
A signed business associate agreement is the entry ticket, not the destination. The agreement establishes that the vendor may handle PHI and defines breach notification duties. It says nothing about how the system behaves on a Tuesday.
Encryption needs to cover data at rest and in transit, with the storage layer encrypted at the object level and keys managed separately from the application. For plans with stricter internal policy, customer-managed keys let the plan revoke access unilaterally, which changes the risk conversation considerably.
The minimum necessary standard has real teeth in document processing. A 200-page medical record contains far more PHI than the extraction task requires. A well-designed pipeline pulls the fields needed for the workflow and does not propagate the full record downstream. Redaction of non-required PHI before a document reaches a reviewer queue is one of the highest-value controls available, and it is one that template-based systems generally cannot do because they do not know what the surrounding text means.
Access control has to be role-scoped and document-type-scoped. A person working vendor invoices in the ERP queue has no business reading clinical records that arrived in the same batch. Segmenting review queues by document type is both a compliance control and an efficiency gain, since reviewers get faster when they see one kind of document all day.
Audit logging must capture who viewed what, when, and what changed. Field-level change history matters more than document-level access logs, because the question during an investigation is usually whether a value was altered, not whether a file was opened.
Data residency and retention deserve explicit configuration. Some plans require that PHI never leaves a specific region. Many require that source documents are purged after a defined window once extraction is complete and the record has posted downstream. Retention should be a policy setting per document type, not a global default.
Model handling is the newer question, and it is the one security teams now ask first. The plan needs a clear answer on whether document content is used for model training, whether inference runs in a tenant-isolated environment, and whether any content leaves the plan's designated boundary. For payers with the strictest requirements, deployment inside the plan's own cloud tenancy removes the question entirely.
Human review needs the same controls as automated processing. Review interfaces are where PHI is most visible to the most people, so session timeouts, watermarking, download restrictions, and screenshot policy all belong in the design rather than in a training deck.
Financial documents in a payer environment have a specific destination, and for a large share of plans that destination is SAP. The integration path depends on which parts of the landscape are in play.
Vendor invoices from TPAs, review organizations, and recovery firms post as accounts payable documents. In S/4HANA this typically means creating the supplier invoice through the standard OData API or through a BAPI call, with the extracted header fields mapping to invoice number, supplier, invoice date, gross amount, and tax, and line detail mapping to cost center, GL account, and internal order where the plan tracks claim-related spend at that level. Three-way matching applies where a purchase order exists, and two-way matching against a contract rate applies where it does not.
Plans running FI-CA for premium and member-level financial processing have a different pattern. Documents that adjust member financial position, such as retroactive premium changes triggered by an enrollment exception, post as FI-CA documents rather than standard AP entries. The extraction layer needs to know which posting path applies, and that decision is driven by document classification, which is why classification quality determines integration quality.
Master data is the quiet dependency. Supplier records, cost centers, GL accounts, and tax codes all have to resolve before posting succeeds. A pipeline that extracts a vendor name but cannot map it to a supplier ID has moved the manual work rather than removed it. The mapping layer should hold a vendor alias table that grows as new senders appear, with unmatched vendors routed to a small exception queue rather than failing the whole document.
Idempotency matters more than it sounds. Duplicate invoice submission is common in payer AP because vendors resend when payment is slow. The posting layer should check invoice number plus supplier plus amount against existing documents and block the duplicate rather than creating it and relying on someone to catch it later.
Attachment linking closes the loop. The source PDF should attach to the posted SAP document through ArchiveLink or the equivalent object services path, so that anyone reviewing the entry six months later sees the original invoice without leaving the transaction.
For plans on Oracle the mechanics differ, and the choice usually comes down to volume and timing.
Oracle Fusion Cloud ERP supports invoice creation through REST APIs for real-time posting, which suits low-to-moderate volume where speed matters. High-volume batches are better served by the FBDI templates, where the extraction layer produces the interface file, uploads it, and triggers the import process. A practical hybrid runs REST for exception-free documents during the day and a nightly FBDI batch for anything that cleared review after cutoff.
Plans still on E-Business Suite use the AP open interface tables, populating the invoice interface and interface lines and then running the Payables Open Interface Import. The pattern is older but well understood, and it handles volume comfortably.
Supplier resolution carries the same weight as in SAP. Oracle supplier sites add a dimension, because the same vendor may bill from multiple locations with different payment terms. Extraction should capture the remit-to address and use it in site resolution rather than defaulting to the primary site.
Descriptive flexfields are worth planning early. Payer AP often needs to carry a claim number, member reference, or recovery case ID on the invoice for downstream reporting. Mapping those extracted values into DFFs at posting time avoids a reconciliation project later.
Approval routing in Oracle picks up automatically once the invoice exists, which means the automation boundary sits at document creation rather than at payment. That boundary is the right one. The system creates a clean, coded, attachment-linked invoice, and the plan's existing approval hierarchy decides whether it gets paid.
The headline number people expect is headcount, and that is usually the wrong place to look first. Most payer operations teams are already short-staffed and carrying a backlog. The first thing automation buys is not fewer people, it is the disappearance of the backlog and the end of the two-week catch-up cycle after every absence.
Turnaround time is the metric that moves fastest. A provider dispute that took six days to reach an examiner reaches them the same morning. That matters because dispute resolution timelines are regulated in most states, and missing them creates both penalty exposure and provider abrasion. Provider satisfaction surveys are dominated by how long things take, not by whether the final answer was favorable.
Recovery yield improves for a less obvious reason. Subrogation and overpayment recovery both run against statutory clocks. Documents that sit in a queue for a week burn a meaningful fraction of the available window. Pulling lien notices and recovery correspondence into the workflow on arrival gives the recovery team more working days on every case, and recovery is a volume business where a few extra days per case compounds.
AP accuracy improves in a way finance notices at close. Duplicate payments to recovery vendors are a persistent leak at most plans, because the same vendor invoices repeatedly for related cases and the invoice numbers look similar. Automated duplicate checking at document creation catches these before they become payments.
The people who used to key data end up doing exception work and vendor relationship management, which is better work and usually keeps them longer. The eleven-person mailbox team at the plan described earlier does not become three people. It becomes eleven people who handle a larger volume, resolve the genuinely ambiguous cases, and stop working Saturdays in January.
The instinct is to start with the highest-volume document type, and that is often a mistake. High-volume types tend to be the ones that already have partial automation and internal political ownership.
A better starting point is the document type with the worst ratio of manual effort to business complexity. Vendor invoices from TPAs and review organizations usually win on this measure. The volume is meaningful, the extraction is well-bounded, the destination system is clear, and the value shows up in a financial metric that leadership already tracks. Success there buys the credibility to take on disputes and medical records, which are harder and higher-stakes.
Run the first document type in shadow mode for two or three weeks. The automation processes everything, humans continue to process everything, and the two outputs get compared field by field. This produces a real accuracy number rather than a vendor benchmark, and it surfaces the edge cases that no requirements document predicted. Plans that skip shadow mode usually end up doing it anyway after the first production surprise.
Set the confidence threshold high at launch and lower it deliberately. Starting at a level where 40 percent of documents post automatically and 60 percent route to review builds trust faster than starting at 90 percent automatic and spending the first month fixing bad postings. The ratio inverts within a quarter on most document types.
Bring security into the design conversation at the start rather than at the review gate. The controls described above are much cheaper to build in than to retrofit, and a security team that helped design the redaction and retention policy is a considerably faster approver than one that received a finished system.
The claims platform will keep doing what it does well. The paperwork orbiting it is the part that has been waiting, and it is now the part where the gap between what is possible and what most plans run is widest.
Artificio processes claims-adjacent documents for healthcare payers with AI agents that classify, extract, and validate without templates, and posts the results directly into SAP and Oracle with full audit trails and PHI controls built into the pipeline.
Head IT Operations - Co Founder of Artificio
See it in your SAP environment
Bring us a document, a process, or a bottleneck. We'll show how Artificio captures, validates, and posts into SAP — then scale from there.
Security & compliance
ISO 27001:2013 certified, SOC 2 Type 2 compliant, GDPR and HIPAA ready. Every agent action is logged, auditable, and runs in isolated environments.
