An ERP permitting module can be enough for a city with simple, low-volume permits and few departments involved. GIS-based software tends to fit better when one property ties together zoning, permits, inspections, code cases and public works.
The reason is structural. Most ERPs are organized around accounts and transactions, while community development work is organized around places.
If your staff keep a spreadsheet beside a "unified" system, or open a separate map to check what a permit record can't show them, the module is probably the wrong foundation for that work. Keep the ERP for finance, and give community development a system built around the parcel.
Use this comparison as a first pass. Most cities will land in both columns, so look at where your biggest problems sit.
| Your situation | An ERP module may be enough | GIS-based software is likely a better fit |
|---|---|---|
| Permit mix | A few standard permit types with similar steps | Many permit types with different review paths |
| Location rules | Few overlays or site-specific conditions | Zoning, overlays or floodplains often affect review |
| Departments | One or two teams handle most of the process | Planning, building, code and public works all touch the same properties |
| Field work | Light inspection volume, with little need for property history on site | Inspectors and crews need property history in the field |
| Public questions | Routine questions are manageable by phone | Zoning and status questions take up significant staff time |
| GIS use | Maps play a small part in daily decisions | The city already relies on GIS, especially Esri ArcGIS |
An ERP is very good at questions like these: How much was invoiced? Which fund did it post to? Who approved the purchase? Those answers depend on consistent rules across every department, which is why cities want one financial system.
Community development staff ask a different set of questions:
Every one of those questions starts with a location. In many ERP modules, the address is a field on a transaction record. In a GIS-based platform, the parcel is the record that permits, inspections, cases and work orders attach to.
Some ERP suites now offer map views or connections to Esri, so the existence of a map proves little. The useful test is what the map does. Can staff start from a parcel and see everything tied to it? Can zoning or an overlay shape how an application is reviewed? Or is the map a picture attached to a record?
The difference is easiest to see in ordinary moments of the workday.
| Moment in the work | When location is a field | When the parcel is the record |
|---|---|---|
| "What can I build here?" | Staff check the zoning map, the code and permit history separately | Zoning, allowed uses and history for the parcel appear together |
| Application review | Reviewers confirm overlays and nearby activity by hand | Reviewers see the parcel's zoning, overlays and open activity with the application |
| Field inspection | The inspector looks up history in advance and enters results later | The inspector opens the property on site and logs the result there |
| Code enforcement | Cases sit in a separate log that permit staff may not check | Open cases appear on the same property as permits |
| Public works | Work orders live in another tool | Work orders and assets sit on the same map |
| Resident questions | Answers come by phone or at the counter | Residents look up their parcel and zoning online |
| Leadership reporting | Someone exports and merges spreadsheets | Leaders see activity and patterns by area |
Leaders who want everything in the ERP have good reasons. Fewer vendors mean fewer contracts, fewer logins and fewer integrations to maintain. A second platform does add a vendor and a connection that someone must own.
Still, a single system doesn't guarantee a single version of the facts. If an ERP module holds its own copy of parcels and addresses, that copy can drift from the city's GIS. When staff export records to spreadsheets to finish their work, the city has more versions of the truth, inside a system meant to prevent them.
A more practical goal is one authoritative source for each kind of information. The ERP stays authoritative for money. The GIS stays authoritative for place. Community development software sits between them and handles the day-to-day work, while fee and payment data still need a defined path to finance.
A bundled permitting module can look free because it doesn't add a line to the budget. Its real cost is staff time, and you can estimate that with four numbers from your own department:
Annual cost = weekly inquiries × hours per inquiry × 52 × hourly rate
Here is an illustrative example, using made-up inputs. A department handles 150 routine zoning and status inquiries a week, at 10 minutes each. That comes to 25 hours a week, or 1,300 hours a year. At a loaded rate of $40 an hour, those inquiries cost $52,000 a year.
Not all of that time disappears with better software, and some inquiries will always need a person. Even so, the calculation turns a vague complaint into a figure a city manager can weigh.
Some costs are harder to count but still belong in the discussion. Slow reviews delay permit fees, hold up construction and push back the tax revenue that finished projects bring in.
The strongest case for change comes from your own records. Set aside a few hours and trace ten recent applications:
Then replace general frustration with findings. "The system is clunky" is easy to dismiss. A count from your own files, in the form "X of ten applications required staff to leave the system to confirm zoning," is much harder to ignore.
Tie each finding to something leadership already tracks: turnaround time, staff capacity, fee collection or resident complaints.
Ask each vendor to answer these using your city's real parcels, including a difficult one such as a split lot or a property under several overlays.
MuniSync is ViewPro's community development platform, built with Esri ArcGIS. It connects GIS, codification platforms and departmental systems into one shared view, so departments work from the same context and cities get more from the GIS they already have.
MuniSync.ai adds chat and voice assistance on the same Esri-supported GIS data. Users can get parcel summary reports, check allowed land uses and ask about the development potential of a site within city limits.
ViewPro is an Esri Partner Network member with the State & Local Government Specialty, and its team comes from city planning. ViewPro also helped the City of Burkburnett, Texas, modernize work order management with ArcGIS.
Book a demo to see MuniSync with your own city's data.
It is a permitting or licensing add-on within an enterprise resource planning system, the software many governments use for finance, payroll and purchasing.
Yes. It can suit a city with simple permit types, modest volume and little coordination between departments. The ten-application audit will show whether your city fits that description.
Not usually. The ERP can keep handling finance, payroll and purchasing, while a dedicated platform manages planning, permits, inspections and code cases.
It is permitting software that ties each application, inspection and related record to a location on the city's GIS. Staff can see zoning, prior permits and open cases for a parcel at once.
It can, if the two systems aren't connected. Before you buy, confirm exactly what moves between them, how often, and who owns the connection.
In a small department, a few people cover many roles. Time spent chasing records or answering routine questions comes directly out of their review and field work.