A QuickBooks portable file (.QBM) is a compressed, stripped-down copy of your company file, built to be emailed or moved to another computer. It leaves out the transaction log and temporary files your .QBW carries, so it's small enough to attach to an email, but you have to restore it into a full file before you can work in it.
1. Know when you actually need one. A portable file is for moving or sending a copy of your company file, to an accountant, to another office, to yourself on a different computer. It's not a substitute for a real backup (that's a separate .QBB file) and it's not something you work inside directly.
2. Create it. With the company file open in single-user mode as an admin, go to File > Create Copy, choose Portable Company File, give it a name, pick a location (your desktop is simplest), and save. QuickBooks compresses everything into a single .QBM file.
3. Send or move it. Because it's compressed and stripped of the transaction log, a .QBM is almost always small enough to email as an attachment or move on a USB drive, something a full .QBW often isn't.
4. Restore it on the receiving end. Go to File > Open or Restore Company, choose Restore a portable file, select the .QBM, and pick where to restore it to. QuickBooks rebuilds it into a working .QBW company file.
5. Treat the restored copy as the live file from there. Once it's restored, work continues in the new .QBW the same as any other company file; the .QBM itself was only ever the transport format, not a file you edit.
The most common mistake isn't technical, it's version confusion. Once a .QBM has been emailed around to a couple of people, there's often more than one copy floating around with no obvious way to tell which one reflects the most current data, so someone restores the wrong one and loses work that happened after it was created.
The other common mix-up is treating a portable file as a real backup. It's close enough that people assume it covers the same ground, but it's built for transport, not disaster recovery, and relying on it as your only backup leaves real gaps.
Instead of someone manually creating and emailing a portable or backup file whenever an accountant asks for one, a current copy gets generated and delivered automatically on request or on a schedule.
Instead of a .QBM getting emailed around with nobody quite sure which attachment is the latest, the current file lives in one shared location that updates itself, so there's no version-guessing before a restore.
Tell us who asks for a copy, an accountant, a second office, and how often, and we'll tell you whether that handoff can happen without someone creating and sending a portable file by hand each time.
Tell us who needs access to a current copy of your QuickBooks data and how that request usually comes in, and we'll tell you if it can be automatic instead of a manual export each time. Portable files are one small example; n-frames automates whatever else in the business still runs on someone doing a manual handoff.
Let's talk →The .QBW is your actual live company file, the one you open and work in day to day. The .QBM is a compressed, portable copy of it made specifically for moving or emailing, and you can't work inside a .QBM directly, you have to restore it back into a .QBW first. Neither is the same as the .TLG transaction log that sits beside your .QBW logging changes for crash recovery.
Attach the .QBM like any other file, it's compressed small enough for most email providers' size limits. For a file carrying real financial data, it's worth password-protecting it or using a secure transfer method instead of sending it as a plain attachment, since .QBM files aren't encrypted on their own.
No. A backup (.QBB) is the more complete snapshot meant for disaster recovery. A portable file (.QBM) is a slimmer version meant for transport, emailing or moving a copy to someone else. Don't rely on a portable file as your only backup.
Yes, and that's exactly what makes it risky if you're not careful: restoring fully replaces whatever's open at the destination. If there's already a live file on the machine you're restoring to, confirm which version is actually newer first, so you don't overwrite recent work with an older snapshot by mistake.