Short answer

Often yes, and it turns on two things: is the file itemised, and does it carry locations?

Civic.ly needs one row per real thing (one row per bench, not "22 benches") and a location for each row. Latitude and longitude is best; a what3words address is fine. Given both, we can create the records for you and hand back a spreadsheet of what was created, with a link straight to each new record.

If the file is itemised but has no locations, it can still be used. You create the assets yourself by walking the site and photographing them, and we then load the spreadsheet's detail onto those existing records, matched on your own reference number.

If the file is not itemised, neither route works until it is, because there is nothing to create one record per.

Photos are always yours to attach. We cannot attach them for you in either route, but we can name them in the sheet we hand back so it is a short, repetitive job rather than a hunt.

Send the file over before you plan around any of this. Whether it works is a judgement someone has to make by looking at it.

Detail

The two things a file needs

Itemised: one row per real thing. Civic.ly works at the level of the individual item that gets inspected, serviced and carries its own history. Most council registers were built for an accountant rather than for field operations, so a single line covers a whole playground and "22 benches" sits on one row. That cannot be turned into 22 records without someone redoing the itemisation by hand.

Located: a point per row, accurate to within a few metres. In order of preference:

  • Latitude and longitude columns. Best, and unambiguous.
  • A what3words address. Fine. It identifies a 3 metre square, which is close enough for a bench, a bin or a tree.
  • A postal address or a free-text location ("Recreation Ground"). Not enough on its own. It tells you which site, not which bench.

Councils already holding their assets in Parish Online or Pear Mapping have proper coordinates, and we have imported from both.

Route 1: the file has locations

We create the records, and you get back a spreadsheet with one row per asset, a direct link to each new record, and, where your file named a photo, the photo filename alongside it. Adding the photos is then click the link, drag the named file onto the record, next row.

This is the route one town council took in August 2026 with 170 bins surveyed on a spreadsheet with what3words. 167 went in with map pins first time.

Route 2: the file has no locations

This is the common case for a survey report or an old register, and it is worth knowing it is not a dead end.

  1. You capture the assets, walking the site and photographing each item. The photo's GPS places it on the map.
  2. Each record carries your own reference from the spreadsheet, in the External ID field (it is on the asset record, and you can show it as a column on the asset list and filter on it).
  3. We then load the spreadsheet's detail onto those records, matched on that reference.

For this to work the reference has to be unique across the whole file. That is the part worth checking before anyone starts, because many registers and most survey reports restart numbering at 1 for each site, so the same reference appears several times.

Why capturing in the field is often better anyway

Councils who walk their estate almost always find their spreadsheet was out of date: items gone, items added, conditions changed. So route 2 is not only the fallback for a file without locations. It is a genuine chance to ground-truth the whole register while you build it, and a register built that way is worth more than the one you started with.

Watch-outs

  • There is no bulk-upload button for registers in the app. Where an import is possible, we run it. The Bulk upload control on the asset list is for uploading geotagged photos, which is a different job.
  • Check your what3words before you send them. Three of that council's 170 did not resolve: two contained words that are not real what3words words, and one was a single-letter typo that resolved cleanly to a point in Illinois. A wrong what3words does not look wrong, so it is worth validating rather than eyeballing.
  • Don't build your onboarding schedule around an import until we have confirmed the file works. Send it early for that reason.
  • Photos never come across in either route. If your file names its photo files, say so, because that is what lets us hand back a sheet you can work straight down.
  • A stale register imports its staleness. If nobody has physically checked the estate recently, expect the capture pass to find differences, and treat that as the point rather than the problem.