Yardi Voyager AP automation, checked against payables you already posted.

In a Voyager shop an invoice usually arrives as an image: one file split out of a scanned batch, an upload from a vendor, a utility PDF. A keyer picks the payee and the expense type, types the invoice number and total, fills the detail lines with entity, account, amount and unit, then writes the note that prints on the check. After that it waits for the people who approve it.

For the test, AI reads copies of invoices that are already posted and drafts each payable the way your keyers would have filled it in, with a reason beside every field. Nothing goes into Voyager, PAYscan or anyone's approval queue. Your reviewer opens the posted payable next to the draft and marks each field that differs.

Expense type, before any account. Training notes written for Voyager keyers warn that the expense type chosen on the header decides which GL accounts the Details tab will offer: pick the wrong one and the right account simply isn't there. An invoice that mixes repairs and supplies goes under a combined type. Every company builds its own list of expense types, so the draft chooses from yours and says plainly when one invoice spans more than one.

An invoice number used once per vendor. Voyager expects each invoice number to be unique for its vendor, and the same keyer guide tells staff never to get past the error by adding a digit, but to look for the earlier entry. Utility bills often print no invoice number, so shops set a house rule, for example part of the account number joined to the due date. The draft applies your rule, checks every number against the payables you send, and names the earlier payable a repeat matches. It never changes a number to make it fit.

Lines that draw on a purchase order. Software that hands payables to Voyager documents the limits: the PO must be open and approved, the PO line must sit under the same property as the payable line, and the line can't exceed the PO. A plumber's invoice that runs past its PO, or a PO raised under a sister property, stops there. The draft names the PO line it matched, the balance it saw on your PO export and any overage. On capital work, Voyager's job cost side adds a job, a cost code and often a contract with retention held back, so those lines are marked for your project accountant.

What the vendor reads on the check. The first notes box on a Voyager payable prints on the check, which is why shops put the unit, the service month or the full utility account number there. A payable can be set to consolidate checks, or marked exempt from 1099 when your accountant says a payment shouldn't count toward the vendor's total, and some vendors are paid through a separate remittance vendor. Credits go in as positive amounts with the type switched to credit. The draft fills each of these the way your posted payables show your team does it.

Workflow starts at validate. In PAYscan, an invoice saved without validating can stall the approval workflow, and each step passes it to the next person in line. Vendors on VENDORCafé, Yardi's vendor portal, receive work orders and purchase orders there and submit invoices through it, so some invoices show up already pointing at a PO. Your reviewer, often the AP supervisor or whoever keeps your Voyager vendors and accounts in order, will look hardest at expense types, repeat invoice numbers and PO lines: the places where a wrong guess is refused, or worse, accepted.

Meet the success criteria and the job runs on new invoices for about 30 days.

Each draft goes to someone on your AP team, who accepts it, edits it or returns it before anything is keyed. Approved payables reach Voyager the way your Yardi administrator decides, keyed from the draft or loaded with tools you already license, and then pass through the same approval workflow as every other invoice. Your team still cuts every check.