Architecture Firm Software Problems: The 7 That Eat Your Fee, and How to Avoid Them

Why does just show us live fee burn become a deliverable model?

The request sounds like a report. Show the project architect what she has spent against the phase, daily. Then the first honest question arrives: spent against what. Fee burn is only meaningful next to percent complete, and percent complete for a construction documents set is a function of sheets released, details resolved, consultant coordination cleared and quality control comments closed. That definition belongs to your firm, not to a vendor, and in most practices it has never been written down.

This is specific to architecture because the deliverable is not a task list. It is a set of drawings whose completeness is a professional judgement made by someone who can look at the set. Every firm holds that judgement in its senior staff and almost none hold it as data, which is why the number gets typed into a field the day before invoicing and then drives billing, revenue recognition and staffing.

The fix is to encode your own deliverable model before writing the reporting. Phases from your agreements break into a task tree with weights. Sheets and details report their own status from the model. Quality control comments close against tasks. Percent complete becomes a computed number the project architect adjusts with a reason rather than invents from scratch. Firms that skip this ship a dashboard showing hours against fee, which every principal already has, and the spreadsheet on the studio director's laptop stays open.

What goes wrong when a decade of project data is migrated?

This is the line item firms underestimate most often, usually by a factor of two. Time entries move cleanly because they are rows in an accounting system. Everything that makes them meaningful does not. Phase structures changed as the firm adopted different agreement templates, so the same phase name means different scope in 2017 and 2024. Fee allocations were amended by change orders living in Word files, consultant agreements were tracked in a folder, and projects were renumbered when the office reorganised.

The architecture specific trap is that your closed project history is the asset that makes forecasting useful. A model trained on your own completed work, knowing project type, delivery method, area and consultant mix, is what flags at week three of construction documents that this job is tracking like three previous ones that landed over. Mangle the history and you destroy the only training data that is genuinely about your firm.

The fix is to migrate active and recently closed projects with full fidelity on phases, fees and time, and to archive older projects in a queryable read only form rather than forcing them into the current model. Map historical phase names to current ones with an explicit crosswalk and keep both, so a comparison across a decade is possible and honest. Then reconcile before go live: regenerate the work in progress position for three closed months and compare it to what was reported at the time. If those disagree, you have found the defect before anyone bills from it.

Why do Deltek, Revit and Procore integrations break after launch?

Integration is forty to sixty percent of the effort in this category and the three that matter fail in different ways. Accounting integration with Deltek Vantagepoint or Ajera is straightforward to read and awkward to write, and older on premise installations may offer a database view and a nightly file rather than a modern interface. Revit and Autodesk Construction Cloud give you the sheet index and published sets, and the work there is genuine engineering rather than configuration, so a schedule that assumes a week is wrong. Procore holds the contractor's requests for information and submittals, and access depends on their partner tiering, which is a conversation with Procore rather than a line in your budget.

What breaks after launch is cadence rather than connection. A nightly sync misses a timesheet correction posted after the run, so a project shows a burn figure finance has already changed. A published set lands in Autodesk Construction Cloud while your sheet list rebuilds weekly, so for days the record of what was issued is incomplete. Neither raises an error.

The fix is event driven refresh where the source supports it, plus a visible data age on every derived number, so a project architect can see the burn figure is based on time through Tuesday. Reconcile nightly against the accounting system and raise a difference report rather than trusting the sync silently. And start the Procore access conversation before the build kicks off rather than during it, because a blocked interface stalls a sprint that has already been paid for.

What happens when construction administration and the issuance record are not covered?

These are the two gaps that cost money quietly. Construction administration is where the firm's most expensive people do the least tracked work. A request for information arrives in the contractor's system at ten to five. The project architect reads it on her phone, thinks overnight, calls the structural engineer, drafts a response and closes it two days later. Three hours of senior time, unattributed and unbilled, repeated across six active projects until a phase priced at eight percent of fee is running at fourteen.

The issuance record is the same problem from the risk side. The sheet index says one thing, the transmittal log another, and the contractor is building from a set that included two sheets nobody logged. When a dispute lands, a contract administrator spends a day and a half reconstructing what was issued, to whom and when, from markup sessions, email and a shared folder.

The fix on construction administration is to pull requests and submittals into your own register the moment they open, route by discipline, and attach time to every response whether logged or estimated from the review session. That gives you requests per week per project, response time against the contract requirement, and hours consumed against the phase fee, which is what makes an additional services conversation defensible. The fix on issuance is to make the issue record the spine: every issuance carries its sheet list pulled from the model, its recipients, its date, its reason and a hash of the file stored in your own account, linked to the change that caused it and the hours it consumed. Your professional liability carrier will treat that record as evidence, so it needs a defensible timestamp and recipient log rather than a folder of emails.

Should you build custom or configure what you already own?

Configure and stop if you are a single office under roughly fifteen people with short, similar projects. Monograph plus your accounting package will run you fine and a custom build at that size is vanity. BQE Core is a reasonable home for a small to mid sized practice wanting time, billing and project tracking together. At that volume the spreadsheet is not really lying to you.

The important position is what you should never build: the general ledger. Deltek Vantagepoint and Ajera are good at accounting and poor at operations, and firms that try to replace their accounting system inside the same project almost always regret it. Keep them as the system of record for money and build the operating layer above, the layer that knows what a phase, a sheet, a request for information and a consultant are.

Build when the signals cluster, and they do cluster. Someone is effectively employed rebuilding fee burn reports every week. You run more than forty live projects across more than one office. You have written off more than a hundred and fifty thousand dollars in a year on overruns you found late. Your project architects have stopped opening the accounting reports entirely. Or you are paying for an accounting system, a project information platform, a contractor seat, a spreadsheet tool and a markup product and still cannot answer which five projects are bleeding right now in under an hour.

How do hidden costs get into an architecture software quote?

Five items account for most overruns and none of them appear on a feature list. Accounting integration depth is first, because reading is easy and writing back time and billing is not, and an older on premise Vantagepoint install may need a middleware layer. Ask for a working read from your actual instance inside the first two weeks, before full scope is signed, rather than accepting a description.

Second is Revit and Autodesk platform work, which is real engineering that people price as configuration. Third is billing document generation in the American Institute of Architects style, which is fiddly, always custom, and expands every time an institutional client insists on their own layout. Fourth is multi entity accounting if your offices are separate legal entities, which changes the data model rather than adding a filter.

Fifth is historical migration, discussed above. In Digital Heroes delivery experience a focused first release covering live phase and fee burn, estimate at completion, a real requests and submittals register and a nightly accounting sync runs 60,000 to 130,000 US dollars over 12 to 16 weeks, with a full platform at 150,000 to 400,000 phased across 6 to 12 months. Quotes materially below that band usually assume clean integration and a small migration, and both assumptions fail in this category.

What separates an architecture build that works from one that fails?

The builds that work ship the burn view first and get project architects logging in daily within the first two months. Adoption by the person spending the money is the whole point, and it does not follow from features, it follows from the number being live, being wrong in ways she can correct, and reaching her before the decision rather than after. Thresholds help: a variance that routes to the studio director at one level and the principal at another, carrying the phase, the fee, the delta and the last four weeks of hours.

They also phase deliberately. Firms that build proposals, resource planning, issuance records and billing before anyone uses any of it end up with an expensive system and the same spreadsheet still open on a laptop.

The builds that fail share three habits. They model a phase as a column on a board, which means the developer has not understood that a phase carries fee, scope and a contractual meaning. They treat percent complete as a field rather than a computation, so the guessing survives the project that was meant to end it. And they leave the issuance record informal, which is the one deliverable your carrier may need. Ask any prospective developer to model project, phase, task, fee allocation, consultant agreement, issuance, request for information and time entry on a whiteboard, and to explain how percent complete and estimate at completion are computed across them. If they cannot, they will learn on your budget.