Filed October 26, 2026

As-applied maps vs. prescription maps: what's the difference?

Aerial view of rolling cornfield rows at sunrise.

Pull up a grower's file in the fall and you'll usually find both layers sitting in the same folder: a prescription map from spring and an as-applied map from the same field, same pass, same crop year. They look similar on a screen, both colored in zones, both tied to the same boundary. But one is a plan and the other is a record, and mixing them up when you're reconciling a grower's input bill or troubleshooting a skip is how mistakes happen.

The prescription file is the plan

A prescription map, or Rx file, is built before the equipment ever enters the field. It's a zone-by-zone rate script generated from whatever data you're using to carve up the field: soil type, yield history, or a vigor layer pulled from imagery through the season. Each zone gets a target rate for seed, fertilizer, or chemical, and the file gets exported in whatever format the grower's controller reads, usually a shapefile or an ISOXML file loaded onto a USB stick or synced through the display.

The prescription is instructions. It doesn't know whether the planter hit 34,000 seeds in that heavy zone or whether the sprayer's boom section shut off three seconds late coming out of the end rows. It's the target, not the outcome.

As-applied data is the record

As-applied data comes off the rate controller after the pass, not before it. Every second or so, the controller logs the rate it delivered at that GPS point, pulled straight from the monitor's as-applied log. Stack those points over the field boundary and you get an as-applied map: a record of what the machine did, section by section, down to the row or nozzle depending on the equipment.

This is the file you pull when a grower calls asking why the north forty looks thin in one strip, or when you need to confirm coverage before closing out a chemical invoice. It answers a different question than the prescription does. The prescription says "apply 1.2 gallons here." The as-applied log says "the controller delivered 1.1 gallons here, and skipped this eighteen-foot strip near the waterway entirely."

Why the two don't line up

Controllers lag. There's a response delay between the signal telling the rate controller to change and the change happening at the metering unit, especially on older equipment or with granular fertilizer that doesn't respond as fast as liquid. Overlap on point rows, boom section control cutting in and out near terraces, an operator manually overriding a rate because the planter was bridging in wet residue. None of that shows up in the Rx file. All of it shows up in the as-applied log.

For a field with clean geometry and a newer controller, the gap between planned and applied might be small enough that nobody notices. For an irregular field with a lot of point rows and waterways, the gap can be the difference between a zone that got treated and one that only looks treated on the prescription map.

Reading them side by side

The real value shows up when you overlay the two. Lay the as-applied layer on top of the Rx zones and you can see where the controller tracked the script and where it drifted, whether from lag, override, or a nozzle that was partially clogged all afternoon. That comparison is also how you build a better prescription next time. If a zone consistently under-applied relative to plan, that's worth flagging before you cut next season's rate script, not after the grower asks why yield came in flat in that corner.

That's the loop a prescription built from in-season biomass and vigor passes is meant to close. Instead of writing one static zone map in spring and hoping it holds all season, a script built from weekly vigor gradients gets the zones and rates re-cut as conditions change in the field, with the as-applied log from the last pass available to check against before you commit to the next one.

If you're cutting seed, fertilizer, and chemical rate scripts for grower accounts this season, see what Field Variability can put in front of your controller before the next pass.

Start a project

← Back to the blog