Getting the output into your systems.

Every vendor page in this category has an integrations grid with green ticks next to Procore, Autodesk and Bluebeam. Ours does not, because the programs make no API calls. What they do instead is write the file each of those systems already imports, with the column names its importer expects.

That is a real trade-off and it is worth being clear about both halves of it. You lose automatic sync: somebody clicks import. You gain two things — a tender package under NDA is never handed to a connector, and a wrong number gets caught in a spreadsheet instead of after it has already written itself into your live budget.

Into Procore

Three of the eight programs write Procore-shaped files, each for a different stage of a job.

• AI Estimator → budget import CSV. Cost code, description and amount, split by cost type. This is the estimate becoming the project budget without anybody retyping a cost code.
• Bid Leveler → bid tab CSV. The levelled comparison across every subcontractor on that trade, in tab form.
• ScopeGuard → issue/punch import CSV. Each finding as a row, using the column names Procore's issue importer expects.

How to run it: export from the program, open the CSV once to confirm the cost codes match your own code structure, since no two lists are, then use Procore's own import tool on the target project. If your cost code structure differs from what came out, fix it in the spreadsheet before importing.

Into Sage 300 CRE or Sage 100 Contractor

AI Estimator writes a job cost budget CSV with labour, material, equipment and subcontract categories separated, and budget hours carried alongside the dollars. That is the shape the job cost import expects, which means the estimate can become the cost budget in one pass instead of being rekeyed by accounting a week later.

The check to do: budget hours are the field people most often ignore and most often need. Confirm they came through before you import, because adding them afterwards means editing the budget instead of loading it.

Into QuickBooks

AI Estimator writes an estimate line CSV at sell price, with taxable lines marked. It imports into QuickBooks Desktop or Online as a customer estimate.

The reason this exists as its own format is that the number a client sees and the number your cost budget carries are different numbers, and the most common way an office loses margin quietly is by exporting one and treating it as the other. Two files, two purposes.

Into Bluebeam Revu

Two programs write Bluebeam-shaped CSVs:

• AI Estimator → quantity summary. Priced quantities carrying the takeoff source reference, so any line can be traced back to the sheet it was measured from. This is the one to use when somebody senior wants to check the takeoff instead of trusting it.
• ScopeGuard → markup summary. Subject, comment and status columns for a markup import.

Worth being precise: this is not a plugin and it does not draw markups onto your sheets for you. It is a summary file that lands in Revu's markup list.

Into Excel, Sheets, or any project log

The general-purpose exports, which is where most people actually live:

Into an email, a letter, or a subcontract

Some of the most useful output is not a spreadsheet at all. SpecChecker writes the drafted RFIs as plain text, one per finding, ready to paste into an email one at a time, instead of a batch nobody reads. ScopeGuard and Bid Leveler write clarification letters the same way, plus the scope paragraphs to attach to each subcontract. SpecChecker also writes the audit summary as Markdown, which is the format for a wiki, a meeting agenda or a weekly report.

These are deliberately plain. They are meant to be edited before they go out with your name on them.

Into your own tooling

SpecChecker, ScopeGuard and Bid Leveler each export the full project as JSON — every finding with its source references intact. ScopeGuard also writes a flattened findings payload if you are posting into an internal endpoint of your own.

This is our own shape, and no published vendor standard, and the file documents itself. It exists so a firm with its own dashboard can feed it from a file instead of waiting for an API that does not exist.

The check to do before every import

One habit, and it takes two minutes.

1. Open the file. Actually open it, in Excel, before it goes anywhere.
2. Check the total. Against your own rough order of magnitude. A number that is out by a factor of ten announces itself immediately.
3. Spot-check three lines against the drawing. Every quantity export carries the source reference for exactly this reason. Three is enough to catch a systematic problem.
4. Import into a test project first the first time you use a given format, so you find out what your own system does with it before it touches a live job.

None of this is a criticism of the output. It is the same check a good estimator does on a junior's takeoff, and the file handoff exists partly so there is a place to do it.

If we do not write the format you need

Send us a sample of the file your system expects — an empty template with the right headers is enough. Adding an export format is small work, and it ships to everyone on a plan at no extra cost, because a format is not a feature tier.

A genuine live connector into your own systems is different work and it is quoted as a custom build, not bolted onto a subscription.