One Platform, Every Department: Why the Agents That Post SAP Invoices Can Also Read Admissions Files and Mortgage Loan Packages

At 8:40 on a Tuesday morning, three people in three different buildings are doing the same job without knowing it.

In Irvine, an accounts payable clerk opens a shared mailbox holding 212 supplier invoices. She opens the first PDF, finds the vendor name, hunts for a purchase order number that may or may not be printed on the document, checks whether the goods receipt exists in SAP, compares the line totals to the PO, notices a freight charge nobody expected, and decides whether the difference falls inside tolerance. Then she keys it into MIRO and moves to invoice number two.

In Coventry, an admissions officer opens an applicant file. There is a personal statement, a scanned transcript from a Nigerian polytechnic, an IELTS certificate, a passport page, and a reference letter that arrived as a phone photograph. She reads the transcript, works out whether an HND maps onto year two entry, checks whether the English score clears the programme threshold, notices the reference letter is unsigned, and decides whether to make an offer, ask for more evidence, or refer the case to a colleague. Then she keys the outcome into SITS and moves to applicant number two.

In Dallas, a loan processor opens a borrower file. There is a 1003, two years of W-2s, thirty days of paystubs, three months of bank statements, and a homeowners insurance binder. He reads the paystubs, calculates qualifying income across a base salary plus variable bonus, checks the bank statements for large deposits that need sourcing, notices the insurance binder expires before the projected closing date, and decides whether the file is ready to go to underwriting. Then he keys his findings into the LOS and moves to borrower number two.

Three departments. Three industries. Three regulators, three vocabularies, three systems of record. One job.

That job is the reason Artificio is built as a platform rather than a catalogue of unrelated products.

The department-shaped software problem

Enterprise software gets bought the way enterprises are organised, which is to say by department. Finance buys an AP automation tool. Admissions buys an application processing tool. Mortgage operations buys a document engine bundled with the loan origination system. Each purchase looks rational on its own. Each one is justified with the same slide about manual effort and error rates.

Five years later the same organisation, or the same holding group, is running seven document tools. Each has its own extraction models, its own confidence scoring, its own review queue, its own permission model, its own audit log format, and its own answer to the question "what happened to this document on the 14th of March". Each one required a separate security review. Each vendor renews on a different date. Each has its own idea of what a "field" is.

The cost that nobody puts on the business case is the cost of seven different versions of the same mental model. When the finance team learns something real about handling low-quality scans, that knowledge stays inside the AP tool. It does not reach admissions, where the same problem shows up as a photographed transcript. When the admissions team builds a good escalation workflow for ambiguous cases, mortgage operations rebuilds it from scratch eighteen months later and calls it an innovation. 

Point solutions optimise a department. Platforms optimise the thing the departments actually share.

What the three jobs have in common

Strip the vocabulary out of those three morning scenes and the same sequence appears every time.

Something arrives, and it arrives messy. It is a mailbox, an SFTP drop, a portal upload, or a shoebox of photographs. Nobody sorted it. The first real act of work is figuring out what each document is, and whether the bundle is complete.

Then a human reads the document and pulls out the facts that matter. Not every fact. A specific set that the downstream decision depends on. Invoice number, vendor, PO reference, line items, tax, total. Or awarding body, qualification, grades, award date, English test score. Or employer, pay period, gross year to date, deposit amounts, insurance effective dates.

Then those facts get checked against something authoritative. The PO and goods receipt in SAP. The programme entry criteria and the qualification equivalency table. The AUS findings and the agency guidelines. Extraction on its own is trivia. Extraction checked against a system of record is work.

Then a decision follows from policy. Post it, block it, request a credit note. Make an offer, make a conditional offer, request more evidence, reject. Clear to underwriting, suspend for conditions, escalate.

Then the difficult cases go to a person. Every one of these processes has a tail. The tail is where the value and the risk both live, and the honest design question is not how to eliminate the human but how to route only the right cases to them, with the evidence already assembled.

Then the outcome gets written back into the system that owns the truth, and something durable records why. Not just what was posted, but which page of which document supported which value, what the confidence was, who approved it, and when.

Six operations. Intake and classify, extract, validate, decide, escalate, write back with an audit trail. That sequence does not change when you change industries. What changes is the noun list and the rulebook.

The same agent wearing three different costumes

Consider what actually differs between the three workloads, field by field.

SAP invoice posting

An agent receives a supplier invoice and classifies it as PO-backed or non-PO. It extracts header and line detail, then resolves the supplier against the vendor master rather than trusting the letterhead. It pulls the purchase order and the goods receipt, performs a three-way match at line level, and applies the tolerance keys already configured in the SAP environment. Where a freight or handling charge has no PO line, the agent applies the policy the finance team wrote down, which might be automatic coding under a threshold and referral above it. Clean matches post through the standard interface. Mismatches arrive in a review queue with the invoice image, the PO, the receipt, and the specific delta highlighted, so a person spends thirty seconds on judgement rather than four minutes on assembly.

AdmissionsIQ application processing

An agent receives an applicant bundle and classifies each item as transcript, certificate, reference, identity document, or personal statement. It extracts awarding institution, qualification title, grades, award dates, and English language scores. It resolves the institution against a recognised-body reference and maps the qualification to the internal equivalency framework, which is the admissions analogue of the vendor master. It checks the result against programme entry criteria, flags missing documents, and identifies conditions that would need to attach to an offer. Straightforward cases produce a recommended decision with the supporting evidence attached. Borderline cases, unusual awarding bodies, and anything touching credibility go to a human with the case already built. The outcome is written back to SITS Tribal so the student record system stays the single source of truth.

MortgageIQ loan file processing

An agent receives a loan package and classifies each document into the standard stacking order. It extracts employer names, pay frequencies, gross and year-to-date figures, deposit lines, balances, policy dates, and coverage amounts. It resolves the borrower and property against the file already open in the loan origination system. It calculates qualifying income according to the rules the lender configured, reconciles paystub year-to-date against W-2 history, surfaces deposits that require sourcing, and checks whether documents fall inside their allowed age at the projected closing date. Complete files move forward. Incomplete or contradictory ones produce a conditions list, in the lender's own language, ready for the processor to send.

Read those three paragraphs again and notice how little of the difference is technical.

The classification step differs by label set. The extraction step differs by field schema. The validation step differs by which master data it resolves against, and a vendor master, a qualification equivalency table, and a borrower file in an LOS are the same shape of object playing the same role. The decision step differs by rulebook. The escalation step differs by who the reviewer is. The write-back step differs by connector.

Every one of those differences is configuration and content. None of them is a different architecture.

What actually stays constant underneath

The shared core is not a marketing abstraction. It is a specific set of components that Artificio builds once and every vertical product inherits.

Document understanding comes first. Splitting multi-document bundles at the right boundaries, handling rotated scans and phone photographs, reading tables that break across pages, and identifying what each page is. A photographed transcript from Lagos and a photographed delivery note from a warehouse floor present the same physics problem.

Agentic extraction comes next, and this is where the architectural choice matters most. Traditional OCR pipelines depend on templates and zones, which means every new supplier layout, every new awarding body certificate, and every new employer's payroll format becomes a configuration ticket. Agents read the way a person reads. They locate the information by understanding what the document is trying to say, which is why the same extraction core can handle a supplier invoice from a company it has never seen and a transcript from an institution nobody at the university has heard of.

Validation against a system of record is the third shared piece, and it is what separates a document tool from a process tool. Every one of the three workloads answers the same question in a different accent, which is whether the claim on this page agrees with the record the organisation already holds.

Confidence and escalation logic is the fourth. A single scoring model, a single way of expressing thresholds, and a single behaviour when a value falls below one. Finance may set a tighter threshold on invoice totals than admissions sets on a reference letter date, but the mechanism is identical, and so is the reporting.

The human review console is the fifth, and it is the component most often underestimated. Reviewers do not want a form. They want the document, the extracted value, the source location on the page, the record it disagrees with, and one keystroke to accept or correct. Build that once, properly, and three departments get a good tool. Build it three times and you get three mediocre ones.

The audit ledger is the sixth. Every value traceable to a page and a coordinate. Every automated decision traceable to the rule that produced it. Every human override traceable to a person and a timestamp. An auditor reviewing SOX controls, an internal quality reviewer sampling admissions decisions, and a mortgage compliance officer preparing for an examination all want exactly the same artefact.

Underneath all six sits the connector layer, which is the only place the platform genuinely has to know about SAP, or SITS, or a particular LOS.

Where the differences are real, and why they still matter

A platform argument becomes dishonest when it pretends the verticals are interchangeable. They are not, and the differences are worth naming precisely.

The regulatory posture is genuinely different. A mortgage file carries obligations around adverse action, disclosure timing, and fair lending analysis that have no counterpart in accounts payable. An admissions process in the UK carries duties around fairness, contextual admissions, and in some cases immigration compliance that no finance system ever encounters. These shape which decisions may be automated at all, not merely how they are automated.

The failure modes are different in cost and in kind. A misposted invoice is recoverable. It shows up in a reconciliation, gets reversed, and costs money and irritation. A wrongly rejected applicant may never find out, never appeal, and never come back. A mishandled income calculation can put a borrower in a loan they cannot carry. Same pipeline, radically different consequences of a false negative, which is why threshold policy is a product decision rather than a technical default.

The volume and latency profiles diverge. Invoice processing is a steady daily flow with month-end spikes. Admissions is violently seasonal, with clearing and deadline days producing weeks of load in a few days. Mortgage volume follows interest rates and moves with very little warning. The same core has to be capable of all three shapes, and the operational design has to acknowledge them.

The domain vocabulary matters more than it appears to. A tolerance key, a conditional offer, and a condition to close are not the same object, and a product that flattens them into "exception type 3" will be rejected by the people who have to use it every day. This is exactly why Artificio ships AdmissionsIQ and MortgageIQ as named products with their own language, their own screens, and their own reference data, rather than shipping a general document tool and asking each department to assemble its own.

The platform is the reason the products can exist. The products are the reason the platform gets adopted.

The economics nobody puts on the slide

The case for a shared core shows up in places procurement does not usually look.

Security and compliance review happens once per platform rather than once per department. Anyone who has taken a document AI vendor through a hospital, a bank, or a university procurement process knows this is not a rounding error. It is months.

Integration knowledge compounds. The team that builds a reliable SAP write-back learns things about idempotency, retry behaviour, and reconciliation that apply directly to writing back into a student record system. The second connector is faster than the first. The fifth is dramatically faster.

Improvements propagate. When the document understanding layer gets better at low-contrast scans because of a logistics customer with terrible fax quality, the admissions customer receiving photographed transcripts benefits without asking for anything. This is the part that most clearly cannot happen across a portfolio of unrelated point tools.

Operating knowledge transfers between teams. A reviewer who has worked an AP exception queue can work an admissions exception queue after a short orientation, because the console, the keyboard shortcuts, the escalation model, and the audit view are the same. For shared service centres and BPO operators, this is a staffing model rather than a convenience.

Governance becomes answerable. When an executive asks how much of the organisation's document work is automated, what the exception rate is, and where the human effort is concentrated, one platform can answer. Seven tools produce seven spreadsheets and an argument about definitions.

How this actually gets adopted

Nobody buys a platform narrative on the first purchase order. They buy a solved problem, then discover the second one is cheaper.

The pattern that works starts with one department that has a measurable, unglamorous pain, usually invoice processing, because the volumes are known and the finance team already tracks cost per invoice. Prove the loop end to end on real documents, including the exception path, including the write-back, including what the auditor sees. Resist the temptation to demonstrate on clean samples, because the tail is the product.

Once that loop is running, the second department is a different conversation. The security review is done. The identity model is done. The review console is understood. The remaining work is the policy pack, the field schema, and the connector, which is a fraction of the original effort and lands in a fraction of the original time.

By the third department, the organisation has stopped evaluating document AI and started operating it. The questions change shape. Instead of asking whether extraction accuracy is high enough, people start asking which exception categories are growing, whether the threshold on a particular field is set too conservatively, and how much reviewer time a single policy change would save. Those are operating questions, and an organisation only gets to ask them once the underlying mechanics have stopped being interesting.

There is a practical sequencing point buried in this. The department you start with should be the one where the system of record is well governed, not the one where the pain is loudest. Automation applied on top of a messy vendor master or a student record system full of duplicates will surface every existing data problem within a week, and the platform will get blamed for finding them. Start where the record is trustworthy, prove the loop, then take the harder department on with a working reference behind you.

The department is a rendering, not the architecture

The AP clerk in Irvine, the admissions officer in Coventry, and the loan processor in Dallas will never meet, and none of them would describe their work as the same. Their org charts, their regulators, their software, and their busy seasons all disagree.

Underneath, they are all doing the same six things to a pile of documents that nobody sorted, against a record that somebody else owns, under a rulebook that changes twice a year.

Artificio builds for that shared shape and then dresses it properly for each department, which is why the same agents that post an invoice into SAP can read a transcript into SITS and a paystub into a loan origination system. Not because documents are all alike, but because document work is.

The invoice is not the product. The applicant file is not the product. The loan package is not the product. The judgement, applied consistently and recorded honestly at a scale no team can reach by reading, is the product. Everything else is a costume.