The most common export mistake is producing one file and expecting it to serve the saw, the office and the ERP. A printed plan in cut order is useless to an import routine, and a CSV is useless to an operator standing at a mitre saw. Four readers, three formats.
Who is actually reading it
PDF — for the saw. The only format the workshop floor really uses. One block per bar, in cut order, with the cut sequence numbered so an operator can work down it and tick off. Print-friendly, legible at arm's length on a bench.
Excel — for the office. What estimators and production managers open. Formatted, multi-sheet, filterable: the plan, the summary metrics, and anything that could not be cut. Lengths stay numbers rather than text, so they can be summed and re-costed directly.
CSV — for other software. Flat, predictable rows with stable column names. This is what ERP systems import and what saw conversion drivers read. Its whole value is that the schema is documented and does not move.
ZIP — for handing over. Everything at once when a job is passed to someone else: the per-length cutting lists, the report and the layout drawing in one download rather than four.
Most fabricators end up using two: a PDF for the floor and a CSV or Excel file for the office system.
There is no universal CNC format for linear cutting
In 2D panel cutting there are real industry formats. PTX — Pattern Exchange — is read by Homag and Holzma beam saws and carries an entire project: materials, cutting patterns, offcuts, destacking data. Other panel saws have their own vendor XML. If you are nesting sheets, there is something concrete to target.
Linear cutting has no equivalent. A cut-to-length saw, a double-head mitre saw and an automatic stop/pusher system are positioning systems: they take a list of lengths (and, where supported, angles) and move a stop. Every manufacturer defines its own layout for that list, and many are configured per installation.
So the industry answer is not a standard file — it is a spreadsheet plus a conversion step. Optimumcut sells its CNC Saw Link as exactly that: a CSV export plus a per-customer "conversion driver" that reshapes it for a specific saw, with custom formats arranged through their sales team. elumatec documents its double mitre saw PC controllers as importing cutting data from common spreadsheet programs, over the network or from a USB stick.
This is worth being blunt about, because software advertising "CNC export" for linear cutting is usually producing either a drawing or a per-machine CSV. A well-specified CSV is the machine-integration format for 1D cutting. What makes it usable is not the file type but the discipline around it: stable column names, documented meanings, and a version number that changes when the schema does. A CSV that quietly reorders its columns between releases breaks every integration built on it.
What about DXF and G-code
DXF is a CAD interchange format: it describes geometry. That is genuinely valuable in 2D nesting, where the cut path is a shape that CAM software turns into a toolpath for a router, laser or plasma table. In 1D, a bar is a line — a DXF of a linear cutting plan is a picture of rectangles, not machine data. A PDF of the layout communicates the same thing more clearly, which is why Barcut Pro produces one and does not offer a 1D DXF.
G-code drives multi-axis contouring machines — mills, routers, lasers. Cut-to-length and mitre saws are not contouring machines: they position a stop and cut. There is no evidence of G-code being used as the interchange format in linear profile cutting, so generating it would mean producing a file aimed at no real controller.
Barcut Pro does not ship a button labelled "CNC export", because there is no specific machine to have tested it against, and a machine file that has never been run on a machine is a liability rather than a feature. Named machine profiles will follow when there is real hardware to validate them on.
What a cutting list has to contain
At minimum: a bar number, the stock length that bar is cut from, the cut sequence, and each cut's finished length and part label.
Beyond that, a plan is only reproducible if the machine settings travel with it — saw kerf, end trim, and the minimum offcut length treated as reusable — because the same parts and the same stock produce a different plan under different settings.
Barcut Pro's CSV export is a single file, cutting-plan.csv: one row per physical cut on every physical bar, with stable column names an importer can be pointed straight at. It is UTF-8 with RFC 4180 quoting, and every column is documented. Job metrics travel in the Excel and PDF exports, which are built for a human reader.
An export must never look more complete than it is
A cutting optimisation can be partial. If you ask for 279 parts and the stock on hand only covers 266, a plan exists — but it is a plan for 266 parts. An export that lists only what it managed to place is not a smaller version of the truth; it is a different claim, and the place it gets discovered is the shop floor.
Every Barcut Pro export states the shortfall explicitly, and distinguishes the two causes, because they need opposite fixes. A part longer than any available stock length can never be cut however much stock you buy — you need a longer bar. A part that fits but ran out of stock just needs more bars. A single job can hit both at once:
UNPLACED PARTS
13 parts could not be allocated.
266 of 279 parts are covered by this plan.
2 x 7400 mm — longer than any stock — add a longer bar
11 x 2400 mm — not enough bars — add more stock
Going further than a file
An export is a file exchange, and for a lot of shops that is the right level: the optimizer writes a CSV, the ERP imports it on a schedule. The other pattern is a direct call at quote time or works-order release, which is what the Engine API is for — parts and stock in, a plan out, deterministic enough that the same request returns the same plan and responses are safe to cache.