Property Preservation Software: Why Rejected Work Only Surfaces at Invoice Reconciliation

Why the money disappears between the work order and the reimbursement

A crew drives to a vacant property in a county two hours out. The order says initial secure, lock change, and debris removal. They do the work, take 40 photos on a phone, and upload them that evening from a diner with signal. Six weeks later the servicer denies the debris line because the before photos do not establish the volume claimed, denies the lock change because the photo does not show the new lock installed on the door with the property address visible, and pays the secure at the allowable rather than the amount invoiced. The field services company has already paid the crew. That gap is not a rounding error and it is not recoverable, because the evidence window closed at the moment the crew drove away.

The stack in this industry is usually a work order platform such as Aspen Grove Solutions or Property Preservation Wizard, a photo capture app like Pruvan, a client portal per servicer that you log into separately, QuickBooks or a similar ledger, and a very large spreadsheet where somebody reconciles what was ordered, what was done, what was paid to the vendor, what was billed to the client, and what came back reimbursed. Those products are real and each is competent at its slice. Aspen Grove has genuine depth on the order and vendor network side. Pruvan is a well built capture tool. The gap is structural rather than technical: the order, the evidence, the allowable, the vendor pay, the client invoice, and the reimbursement claim are five different records in four different systems, and the only place they meet is the spreadsheet, six weeks late.

In the field services projects we have delivered, denials cluster on a handful of causes: non compliant photos, work over allowable without an approved bid, completion documented after the due date, and inconsistent quantity measurement. All are preventable at the point of work, none at the point of invoicing, which is where most operations find out.

Problem 1: allowables are a matrix per investor per state, and most systems store one price list

HUD publishes maximum property preservation allowables that vary by line item and by state. Fannie Mae maintains its own property preservation matrix. Freddie Mac and the VA have their own. A national field services company works several of them at once, and the same task at the same property carries a different maximum, a different documentation requirement, and sometimes a different definition depending on whose loan it is. Then your servicer client layers its own rules on top, and those change by bulletin.

What most platforms do is hold a rate table per client. What they do not do is hold the investor rule set as a versioned, effective dated object that drives both pricing and validation. So a coordinator has to know that this order is a Fannie loan, that this line is over the matrix, and that a bid is required before the crew leaves. That knowledge lives in three experienced people and it walks out at 5pm.

What a custom build does: allowable schedules are data with an investor, a jurisdiction, a line item, a maximum, and an effective date. Every order carries its investor, so the moment a line is priced the system knows whether it sits inside the allowable, requires a bid, or is flat out non reimbursable. The crew is told before the work, not after. When HUD or Fannie publishes an update, you load a new effective dated version and every open order revalidates, which also means you can answer the question nobody can currently answer: how much of last quarter's denied work would have passed under the rule that actually applied.

Problem 2: photo evidence is the actual deliverable, and phones make it easy to fake

You are not selling grass cuts. You are selling a defensible evidence package. The photo requirements are specific and unforgiving: before, during, and after from consistent angles, a date verified image, an address verification shot, a measurement reference for volumetric work, and a completed damage or condition report. A photo taken in the wrong order, or uploaded three days later from a different location, is a denial waiting to happen even when the work was done properly.

What a custom build does: capture is guided and constrained. The app presents the required shot list for that specific line item under that specific investor, and it will not mark the task complete until each required shot exists. Photos are captured in app rather than selected from the camera roll, with device location, timestamp, and a hash recorded at capture so the chain of custody is defensible. Offline is mandatory, because these properties are rural, so the app queues locally and syncs later while preserving original capture metadata. On sync, automated checks run before a human looks: is the property visible, is this a duplicate of a photo from a previous visit, does the geolocation sit within tolerance of the parcel. Duplicate detection across visits is the most valuable quality control feature in this category, because photo reuse is the most common form of contractor fraud and it is invisible to manual review at volume.

Problem 3: the clock started before your order arrived

Inspection and preservation deadlines are set relative to events in the servicer's world: days since delinquency, days since vacancy determination, days since the previous inspection. Your order may reach you two days into that window. If your system starts the clock at order receipt, you will miss deadlines while your dashboard shows green.

What a custom build does: store both dates. The client due date and the underlying investor timeline date, with the order's received timestamp kept separately so you can prove where the time went. Escalation runs off the tighter of the two. Route assignment then considers the deadline rather than only geography, because the standard failure is a crew batching a distant county for next Tuesday when one order is due Friday. A deadline about to be missed should raise a day early, so the client conversation happens before the miss rather than after the denial.

Problem 4: contractor pay and client billing are computed from two different stories

The vendor invoices what the crew says they did. You bill the client what the order and the completion documentation support. The servicer reimburses what the investor allowable and the evidence support. Those three numbers are computed at three different times from three different sources, and the difference is your margin, silently. Most operations discover the shape of that difference quarterly, in aggregate, with no ability to attribute it to a vendor, a client, a line item, or a coordinator.

What a custom build does: one completion record produces all three. Vendor pay is computed from the completed and validated lines at that vendor's schedule, client billing from the same lines at the client schedule, and the reimbursement claim from the same lines against the investor allowable. Every variance is then attributable: this vendor's debris quantities are consistently above the photo evidence, this client denies lock changes at a much higher rate than the others, this coordinator approves over allowable work without bids. Vendor scorecards built from that data are what let you cut the bottom decile of your network with evidence rather than instinct. Chargebacks to vendors for denied work become defensible, which matters, because a chargeback you cannot evidence is how you lose a good crew.

Problem 5: bids are a queue, and queues are where days die

Work over the allowable needs approval before it happens. The bid goes to the servicer, sits in a portal, and comes back approved, denied, or modified, sometimes in hours, often in weeks. Meanwhile the property deteriorates, the deadline runs, and the crew has moved on to another county. Most operations manage this in email and a spreadsheet, and the honest failure rate on follow up is high.

What a custom build does: bids are tracked objects with an age, an owner, and an automated follow up cadence per client. The bid carries the photos and the measurement that justified it, so an approver has what they need on first read rather than after two rounds of questions. Approved bids convert to work order lines automatically with the amount locked, which prevents the classic loss where a bid is approved at one figure and the crew completes at another.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A focused first release, meaning order intake from client portals or files, allowable aware pricing and validation, a contractor mobile app with offline guided capture, routing and deadline management, and completion validation, runs $70,000 to $150,000 in 14 to 20 weeks. A full platform adding bids, three way reconciliation across vendor pay, billing and reimbursement, quality control sampling with duplicate photo detection, vendor onboarding, and per client document packaging runs $180,000 to $420,000 over 8 to 14 months.

What drives price up specifically in mortgage field services: the number of client servicers, because each has its own portal, order format, photo standard, and invoice specification, and each is real weeks of work. Investor coverage, since HUD, Fannie, Freddie, and VA rule sets are four separate models. Offline mobile depth, a genuine engineering requirement here. Vendor compliance tracking, if you carry insurance certificates and licensing per contractor per state. And volume, because dispatching 30,000 orders a month needs queue engineering that 3,000 does not.

What keeps price down: starting with your largest client and one investor, then adding clients. The second costs a fraction of the first if the model was built correctly.

Build versus buy, and when buying is the right call

Buy if you are a regional vendor doing under about 1,000 orders a month for one or two national companies. You are receiving orders in their system anyway, and Pruvan or a similar capture tool plus disciplined bookkeeping will serve you. Building your own would duplicate the client's platform without improving your economics.

Build when two or more of these are true. You hold direct servicer relationships and are therefore responsible for the reimbursement claim rather than just the field work. You run multiple investors, so allowable logic is a real rule engine and not a price list. Your denial rate is material and you cannot attribute it by cause, client, or vendor. You manage a contractor network large enough that quality control has to be systematic and sampled rather than personal. Or you are competing for servicer business on compliance and reporting quality, which is increasingly what these contracts are won on, and your evidence packaging is currently a person assembling PDFs.

How to choose a developer for property preservation software

Ask them to model the domain before you sign. You should see loan and property, order with investor and client due dates, line item mapped to an allowable schedule with effective dates, work event, photo with capture metadata, bid, completion, and three separate financial derivations from one completion. If they draw jobs and photos, they have built a field service app for plumbers and are about to meet a HUD allowable matrix.

Ask how the mobile app behaves with no signal for six hours and a full camera roll. The answer should involve local queueing with preserved capture metadata and a resumable sync, not a spinner.

Ask what they have integrated. Servicer portals, order files, and vendor payment rails are different problems, and screen level integration with a portal that has no API needs an honest answer about maintenance.

Ask who owns the code and the photographic record, in writing, before kickoff. At Digital Heroes the client owns the code from the first commit. Your photo archive is the evidence behind every claim you have filed, and it should never live somewhere you cannot retrieve it from on demand.