What to check before sending a block-heavy drawing to a client

Sending the DWG isn't the whole job

There's a version of this task where you just hit save, attach the file and move on, and for a simple drawing with no external content that's genuinely fine. The moment a drawing is full of downloaded blocks, furniture, hardware, fixtures, and you don't know what CAD platform the client is opening it in on the other end, that casual approach starts to create problems that show up as a confused phone call two days later rather than anything you'll notice yourself. I've been on both ends of that call, and it's always cheaper to spend ten minutes before sending than to spend an afternoon troubleshooting after.

What makes this specific handoff trickier than sharing files internally is that you usually can't just walk over to the client's desk and look at their screen, so any mismatch tends to surface as a slow, frustrating email thread instead of a quick fix, which is exactly the kind of friction a short pre-send routine is designed to prevent.

Find out what you're actually sending it to

This sounds obvious but I skip it more often than I should, and it's the single highest-leverage step. A client on full AutoCAD 2024, one on BricsCAD, and one on a free viewer that can only look at the file, not edit it, all need a slightly different package from you. If you genuinely don't know, ask, most clients can tell you in one line, and it changes everything downstream about how careful you need to be with fonts, dynamic blocks and file version.

I'll usually ask something specific rather than open ended, what program and roughly what version are you opening this in, since that gets a far more useful answer than a general question about their software setup, which people tend to answer vaguely if you let them.

It's also worth pinning down the specific detail of AutoCAD versus AutoCAD LT, since clients say AutoCAD as a catch all term constantly, and if it turns out they're actually on LT, that's the moment any 3D solid geometry in your block library becomes a real problem rather than a minor footnote, since LT simply won't display or edit true 3D solids at all. I've had a client confirm mid project that their AutoCAD was actually LT, and it changed how I packaged the next transmittal completely, stripping any 3D content down to a 2D representation before it went out rather than leaving them to discover the gap themselves.

Purge, audit, and check for the usual suspects

Before anything leaves your machine, run PURGE to strip out unused blocks, layers and linetypes that have accumulated over the life of the project, since there's no reason to hand someone else a bloated file with definitions they'll never use. Follow it with AUDIT to catch any silent corruption. Then scan specifically for dynamic blocks with parameters the client's software might not fully support if they're not on full AutoCAD, and for any 3D solid geometry if you suspect they're on a 2D-only platform like AutoCAD LT.

This whole routine takes under five minutes on a typical drawing, and it's the kind of habit that pays for itself the very first time it catches something, since the alternative is discovering the same issue after the client has already opened the file and formed an impression of how careful your office is with deliverables.

While you're in there, it's worth opening the XREF manager specifically and checking that every reference path is relative rather than hard coded to a folder on your own machine, since a hard coded path is invisible on your system, it just works because the folder happens to exist there, and it becomes a missing reference the instant the file lands on someone else's drive with a different folder structure. This is a genuinely common mistake, mostly because it costs nothing to overlook on your own machine, and it's exactly the kind of thing eTransmit is built to catch and fix automatically if you let it handle the packaging rather than just zipping the folder up by hand.

Package it properly rather than sending a loose file

If the drawing has any XRefs, referenced images, or nonstandard fonts, AutoCAD's built-in eTransmit command bundles the drawing together with every dependency it needs into a single package, so the client isn't left with a missing reference error the moment they open it on a machine that doesn't have your exact folder structure or font library. This is worth doing even for a drawing you think is self-contained, since it's common to forget a block was inserted with an external hatch pattern file or a font that isn't actually part of the standard library. A few minutes spent packaging correctly saves the client, and you, from a frustrating back and forth.

eTransmit also generates a short report listing everything it bundled, which doubles as a quick sanity check on your end, since it's an easy way to spot a reference you'd forgotten was even attached to the drawing before it becomes the client's problem instead of yours.

Fonts, layers and units, the same three culprits again

By now these three show up in almost every compatibility conversation for good reason, they're responsible for the overwhelming majority of the visible problems. Confirm the block library you're sending uses standard fonts rather than anything decorative. Confirm your layer names follow a convention the client will recognize, industry naming standards like the AIA layer system help here if you're working with an architectural client specifically. And confirm drawing units match what the client expects, since a block inserted correctly in a millimeter-based drawing can appear absurdly oversized or undersized if the receiving drawing is set up in inches without anyone catching it.

I'd genuinely put units near the top of the checklist rather than the bottom, since it's the one issue on this whole list capable of making a drawing look completely unusable at first glance, whereas a font or layer naming mismatch is more of a nuisance than a blocker.

Offer a PDF or DXF as a fallback

For a client you're not fully confident will open the DWG cleanly, whether because they're on unfamiliar software or you just don't know their setup well enough to be sure, sending a plotted PDF alongside the DWG costs you almost nothing and gives them something to visually cross-check against once they do open the native file. A DXF export is worth considering too for clients on less common CAD or CAM software, since it's a documented, published interchange format that tends to be supported more broadly than raw DWG across the wider design and manufacturing software ecosystem. Neither replaces the DWG for actual editing, but both make the handoff noticeably less stressful for everyone involved.

I've made this a default part of any client transmittal rather than something I only do when I'm worried, since it costs almost nothing to generate and it consistently comes across as more considerate than just dropping a raw DWG in their inbox and hoping for the best.