What we actually built with AI in a construction management platform
A practical account of using Claude (Anthropic) for invoice matching, PDF plan analysis, and financial oversight in a real Australian SaaS platform.
There's a lot of noise about AI in software right now. Most of it is either oversold ("AI will do everything") or dismissive ("it's just autocomplete"). Neither is useful if you're trying to work out whether there's something worth building.
We've been building a construction management platform for APM Software over the past year. AI, specifically Claude, built by Anthropic, is in production in two parts of the platform. Here's what we actually built and how it works.
What the platform does
APM is a full-lifecycle platform for residential builders. A job enters the system as a lead and moves through estimating, tendering, site management, and invoicing without leaving the platform. The estimating module is built around a custom browser-based drawing engine, estimators measure construction plans directly in the browser, and those measurements drive the cost model all the way through to purchase orders and invoices.
That pipeline creates a lot of structured financial data. And structured financial data is exactly where AI starts to become genuinely useful.
Invoice matching
Residential builders deal with a high volume of supplier invoices. A concrete pour, a frame delivery, a roofing subcontractor, each job generates dozens of supplier invoices, each of which needs to be reconciled against a purchase order.
Manually, this is tedious and error-prone. Someone reads the invoice, finds the corresponding PO, checks the line items match, and flags anything that doesn't. At volume, errors slip through.
We integrated Claude to read incoming supplier PDFs and match them against the relevant purchase order. Claude extracts the line items, quantities, and amounts from the invoice and compares them against the PO data in the system. Discrepancies are flagged for human review. Matches are confirmed automatically.
The practical effect: the reconciliation step that previously required a person to work through a stack of PDFs now takes seconds and only surfaces the ones that need attention.
This feeds into job-level profitability analysis. When every supplier invoice is matched and reconciled in real time, the financial position of a job is always current, not updated at the end of the month when someone gets around to it.
Plan analysis
Construction plans uploaded to the estimating module have a title block, a section of the drawing that contains metadata: scale, revision number, page title, project name. Estimators need this information to set up their takeoff correctly.
Previously, they entered it manually. Now Claude reads the title block from each uploaded page and populates those fields automatically: scale notation, page names. An estimator uploads their plans and the setup is already done.
It's a small time saving on any individual plan. Across a business running multiple jobs simultaneously, it adds up.
Where it's going
The two active integrations, invoice matching and plan analysis, both share a characteristic: they're doing something a competent person could do, but doing it faster and at a scale where errors are more likely.
The direction we're developing toward is using AI as a financial backstop across the whole platform. A job's cost trajectory looks unusual relative to similar jobs. An invoice is out of line with what the PO suggested it would be. A variation has been costed in a way that doesn't match how the rest of the estimate was structured.
These are the things an experienced project manager would catch. The goal is making those checks automatic, not replacing the person, but making sure nothing slips through when someone is managing eight jobs at once.
How we approached the integration
We started with a proof of concept: could Claude reliably extract structured data from the kinds of PDFs this industry produces? Construction supplier invoices are not standardised. They come in every format imaginable. Some are well-structured PDFs; some are scanned documents; some are emailed spreadsheets converted to PDF.
The POC showed it worked well enough to build on. We didn't need perfect, we needed reliable enough that the human review step catches the edge cases, and the automation handles the volume.
That's the right framing for AI in business software generally. You're not trying to replace human judgement, you're trying to reduce the number of things that require it. The cases where Claude gets it right never need a person. The cases where it's uncertain get flagged. The people stay in the loop for the things that matter.
The same pattern turns up everywhere
The specific application here is construction, but the underlying pattern is common. If your business has people reading PDFs and entering data, comparing documents against each other, or reviewing financial data for things that look off — that's the same work. Document processing at volume, matching and reconciliation, anomaly detection over numbers that should behave predictably.
AI integration is worth looking at seriously for any of those. Not as a strategy exercise, but as a specific build: what problem, what data, what does good output look like.
Code Workshop builds custom software with AI integration for Australian businesses. If you're trying to work out whether there's something worth building with AI in your systems, talk to us, we'll tell you honestly.