IP Spreadsheet Audit
Drop in the CSV or Excel file your team actually tracks IPs in. We'll flag overlapping subnets, pools running out of room, and rows that don't parse — entirely in your browser.
Drag & drop your IP inventory CSV or Excel file here
or click to browse — .csv or .xlsx
Confirm column mapping
Auto-detected — adjust anything that looks wrongThis audit is a snapshot. SubnetVault tracks it continuously — get overlap detection on every change.
💾 Save this address planNeed to check just a couple of ranges instead of a whole spreadsheet? Try the subnet calculator or the VLSM calculator to plan new, non-overlapping allocations before they go in the sheet.
Why every IP spreadsheet eventually rots
Every network team starts the same way: a spreadsheet with a few clean columns — client, subnet, VLAN, maybe a location. It works fine for the first ten entries. Then someone leaves, someone else inherits the sheet without the context, and the columns quietly drift. One row has a full CIDR in the IP column. The next has a bare IP with the mask three columns over, because whoever added it copied a different template. A few rows are missing the mask entirely. Nobody notices, because a spreadsheet doesn't validate anything — it just stores whatever you type.
If you run an MSP, this gets worse fast. Every new client site gets provisioned by whoever's on call that
week, usually from whatever router or firewall wizard they had open, and the wizard's default is almost
always 192.168.1.0/24. Multiply that by twenty clients and you don't have twenty distinct
networks — you have the same subnet, reused twenty times, sitting in the same tracking sheet with
straight faces. It's invisible until two of those clients need to be on the same VPN, or share a
site-to-site tunnel, or get merged into the same MSP dashboard — and suddenly two "different" networks
are the same address space, and nothing routes the way anyone expects.
Duplicate static IPs cause a quieter version of the same problem inside a single environment. Someone
hand-assigns .50 to a new server without checking what's already there, because checking
means opening the spreadsheet, scanning a few hundred rows, and hoping they didn't miss anything. They
usually don't miss anything — until the one time they do, and two devices fight over the same address at
2am. None of this shows up as a spreadsheet error. Spreadsheets don't know what a subnet is. They just
hold text.
The other failure mode is exhaustion nobody's watching for. A /29 handed out for "just a few IP cameras" quietly fills up over two years of small additions, and the next camera install fails with no obvious cause until someone manually counts how many of the six usable addresses are actually free. Multiply that across a few hundred rows of client allocations and it's not something anyone catches by scrolling.
This tool exists for the fifteen minutes before a migration, an audit, or a new client onboarding, when you need to know — not guess — whether your spreadsheet is lying to you. Drop in the CSV or .xlsx file, confirm which columns mean what, and it'll do the pairwise overlap math and capacity math a spreadsheet can't do on its own. Nothing gets uploaded; it's the same math the subnet overlap checker runs, just applied to every row in your sheet instead of two ranges pasted into a textarea.