The AP automation rollout fails on approval hierarchy, not on invoice reading

Every AP automation demo goes the same way. An invoice is dropped in, it gets read correctly, coded correctly, and posted. Fifteen seconds.

That part genuinely works. The reason implementations run long is that the demo skipped the two things that consume the calendar: your approval hierarchy, and the state of your vendor and coding data.

Approval hierarchy is a decision nobody has written down

Ask a property management company who approves a $4,200 plumbing invoice at a specific property and you will get an answer that depends on who you ask.

The reason is that approval authority in most operations is a set of conventions rather than a defined matrix. It works because the people involved know each other. It cannot be configured, because there is nothing to configure from.

Building it requires answers to five questions, per property or per property group:

Who approves under the first threshold, and what is that threshold. Who approves above it. Where does capital spend diverge from operating spend, and who owns that. What happens when the assigned approver is unavailable. Which vendor categories bypass approval entirely.

Those are org design decisions. They belong to the controller and the operations leadership rather than to whoever is implementing the software, and they are the item to start before the project rather than during it.

Empty assignment cells are the failure that surfaces at go-live

The specific way this breaks: a per-property, per-role assignment grid with gaps in it.

Property 27 has no regional assigned, because the previous regional left and the reassignment happened informally. Under the old process the invoice went to whoever handled it. Under a configured workflow it goes nowhere and sits.

So the assignment grid needs to be complete before go-live, and reviewing it for empty cells is a specific pre-launch check rather than something to notice afterward. In our own product the grid shows assignments per property and role, and an empty cell means nobody is on deck, which is worth reading as an alert rather than as a blank.

The data work is a prerequisite, not part of the project

Two data sets determine how well automation performs, and neither is something the software fixes.

The vendor master. Duplicates split your coding history across records, so the coding engine learns from four thin patterns instead of one good one. Cleaning the top hundred vendors by spend captures most of the benefit and is about a week of work.

The chart of accounts mapping. AI coding learns from historical patterns, which means it inherits whatever inconsistency is in your history. If the same kind of repair has been coded to three different accounts across properties over two years, the model learns ambiguity, correctly, because the history is ambiguous.

That second one is uncomfortable and worth being direct about. Automation reproduces your coding conventions. Where those conventions were inconsistent, you get inconsistent output and it will look like a software problem.

The fix is to decide the convention before go-live for your highest-volume categories, then let the system learn against the decision rather than against the history.

Sequence by vendor category, not by property

The instinct is to pilot at one property. Better is to pilot on one vendor category across all properties.

Utilities first. Highest volume, most consistent format, clearest bypass case, and a measurable outcome in late fees within one billing cycle. If it works there, you have proof and you have recovered something.

Then recurring contracted services: landscaping, pest control, pool. Same characteristics, slightly more variance.

Then general maintenance and repair, which is where the format variance and the coding judgment live.

Capital and PO-backed spend last, because it involves matching, receipt, and budget interaction, and it is the category where an error is largest.

Property-by-property piloting means every vendor category at once at one property, which is the hardest version of the problem on the smallest sample.

What to measure, from week one

Four numbers, and the fourth is the one that tells you whether it worked.

Automation rate. The share of invoices clearing without human touch. Ours runs at 98%, and a number that starts lower and climbs is normal because the coding is learning.

Error queue volume and aging. How many exceptions, and how long they sit. Aging is the more useful half, because a growing error queue means the exception path has no owner.

Speed to submit, from email receipt to ERP submission, as a distribution rather than an average.

Approval aging, bucketed. Under 1 day, 1 to 3 days, over 3 days. The over-3 bucket is where cycle time actually lives, and watching it tells you which approver or which property is the constraint. This is the number that turns a vague sense that things are slow into a specific conversation.

What the outcome looks like, with what it measures

ResProp eliminates $150K or more in annual AP costs, saves 40 hours a month, and runs a 4.2 FTE efficiency gain.

Being precise about that: those are labor and processing cost figures measured against their prior manual process, at their invoice volume, on their portfolio. They are not a promise about yours, and the honest way to use them is as evidence that the mechanism works rather than as a projection.

What determines your version of the number is your invoice volume, your current cost per invoice, and how much of your AP labor is exception handling rather than processing. The third one is the biggest variable and it is the one most affected by the data work above.

Four things we do not do

We do not clean your vendor master or decide your chart of accounts conventions. Those are prerequisites.

We do not design your approval hierarchy. We configure the one you decide on, including thresholds, escalation, and bypass rules.

We do not replace your ERP. The flow ends in your accounting system, and for our own portfolio that is BillRoute for capture and coding, Coupa for approval where it is in use, and ResMan for GL recording.

We do not process invoices we never receive. Spend that goes out on a property-level card or a manual check never enters the pipeline, and closing that path is a policy decision on your side.

Do one thing before you evaluate software

Write the approval matrix. Every property, every threshold, every alternate approver, every bypass category.

If that document does not exist, no AP automation project can be configured, and building it is where the weeks go regardless of which vendor you choose.

Does yours exist?