Why AP invoice entry on AS/400 (IBM i) is still manual
AP invoice entry on AS/400 (IBM i) stays manual because the last step — getting the invoice into the ERP — is the one most tools skip. Invoices arrive as PDFs, scans, faxes and Excel statements. A clerk finds the vendor on the host, keys the header and every line, checks the total and presses Enter.
Invoice OCR tools turn the page into a CSV or JSON file, then stop. With a legacy ERP, someone still retypes that data, or an integration project has to write into a system nobody wants to touch. The questions that cost money — is this invoice already keyed, does the PO exist, do the lines reach the total — are left to memory, while the people who know the green screens get harder to replace.
How invoice processing automation works
Invoice processing automation with legacy bridge follows your clerks’ path, with the checks a busy person skips.
Invoices arrive where they already go
Forward your AP mailbox, connect it by IMAP or Gmail, poll the SFTP folder your scanning service fills, or upload by API. PDFs, scans, faxes, Word and Excel are all read.
Invoice OCR without templates
AI vision reads each vendor’s own layout, so a new vendor needs no template. A PDF holding a batch of invoices is split into one record per invoice.
Values are checked before anything is keyed
Lines must reach the total and dates must make sense. Vendor, PO and invoice number are checked against your host, and your plain-English AP rules apply.
Keyed, approved and confirmed
The agent finds the vendor through the host’s lookup and fills the invoice screens. A clerk approves the prepared entry in the console or from an email link; the agent submits and reads the record back.
Invoice data entry automation: fields and checks
Invoice data entry automation is only worth having if the data is right, so every value is checked before your ERP sees it.
Vendor
Name, remit-to and tax ID, matched to your host’s vendor record
Invoice
Invoice number, invoice date, due date, payment terms, currency
Purchase order
PO number and receipt references, where printed
Line items
Item code or description, quantity, unit of measure, unit price, line amount
Tax and charges
Tax, freight and discounts
Totals
Subtotal and invoice total, exactly as printed
Checked before entry
- Lines, tax and charges add up to the printed total
- Dates are plausible: no invoice dated in the future, no due date before the invoice date
- The vendor exists on your host, and this invoice number is not already on file for that vendor
- The PO number exists on the host
- Your AP rules in plain English, such as “hold any invoice without a PO number”
When your PO and receipt screens show ordered and received quantities and prices, legacy bridge compares the invoice with them: a 2-way check against the PO, a 3-way check where receipts are shown. A difference is held for a person, never keyed through. It does not replace your ERP’s own matching.
Vendor invoice processing exceptions, handled
Vendor invoice processing is mostly exceptions. Each ends in a clear state: held for a person, or caught.
Totals that don’t add up
If the lines do not reach the printed total, the invoice is read again. If it still disagrees, it is held — never keyed with a guessed amount.
Unknown vendor
A vendor the host cannot find waits for AP to pick the right record. That choice is remembered for the next invoice.
Duplicate invoice already keyed
Keyed by your team already, or sent twice by email and scan: the copy is caught, not entered again.
PO not found on the host
An unknown PO number is held with the host’s answer on screen, so purchasing can check it before anything posts.
Host error message
If the ERP rejects a value — a blocked vendor, a closed period — the clerk sees the host’s message and the screen. Nothing is submitted.
Unclear or corrected values
A smudged amount or handwritten correction is flagged with the exact field and the invoice image. Never guessed.
Accounts payable automation into a legacy ERP: the options
Accounts payable automation into a legacy ERP means one of three approaches. Here is how they compare.
| Criterion | legacy bridge | Invoice OCR + RPA | Manual keying |
|---|---|---|---|
| A new vendor layout | Read by AI vision, no template | Template or training per layout | A clerk reads it |
| Getting it into the ERP | Keyed through your AP screens | A bot scripted screen by screen | Typed field by field |
| Duplicate invoices | Caught, including ones your team keyed | Only if someone builds the check | Depends on who remembers |
| Totals and PO checks | Against the document and the host | Confidence scores on fields | Spot checks |
| Proof it posted | Record read back from the host | A log says the bot ran | The clerk’s word |
| Audit trail | Every keystroke and screen, hash-chained | Separate logs per tool | Only the record itself |
Why extraction alone stops short is covered in document AI; bots, in the IBM i RPA alternative.
Systems it works with
legacy bridge runs in production on IBM i (AS/400, iSeries), including packaged ERPs and custom RPG or COBOL AP applications. Nothing is installed on the host: it connects over TN5250 like your terminal emulator, through an SSH tunnel if the host is not on the internet. Every keystroke and screen goes into a SHA-256 hash-chained audit trail.
The same engine speaks TN3270, VT and HP 6530 and drives legacy web portals and Citrix or RDP desktops, scoped per workflow — see legacy system automation. You start with one real invoice on your own screens; the proof stops before submission and your clerk decides.
