The manuscript in your Scrivener editor and the file that comes out of Compile aren't automatically the same thing. Compile applies its own formatting layer on top of your project, based on whatever preset you've selected, and when that preset doesn't match what you actually wrote, the gap shows up in the exported file, not before.
The export doesn't match the editor
This is the root cause behind most other problems on this list. Compile formats output according to a compile format preset, not a direct copy of your on-screen text, so font, spacing, and indent settings in the preset override whatever you were looking at while drafting. If you never checked the preset against your project, differences only surface once you open the exported file.
Missing or inconsistent scene breaks
A scene break typed as a blank line rather than assigned as an actual Section Break in Compile settings can be collapsed or dropped entirely during export, particularly in ebook formats. The fix is treating scene breaks as a structural setting inside Compile, not just a visual gap in the manuscript.
Fonts that don't carry over
Word and PDF exports generally preserve fonts correctly if the compile format is configured to use them. Ebook exports are less reliable: Scrivener's ebook conversion doesn't always embed fonts, and can strip font-face information so the output falls back to the reading device's default. This is a limitation of the ebook export path specifically, not something a setting reliably fixes.
A table of contents with broken links
Scrivener can auto-generate a working, clickable table of contents. A manually built one is a different story: Compile can strip the links out during conversion, leaving a table of contents that looks correct but doesn't function. Use the auto-generated version unless you have a specific reason to build your own.
Reducing how often this happens
Saving a custom compile preset once you've got settings correct for a project avoids rebuilding them from scratch on the next export of that same manuscript. It doesn't remove the underlying complexity though, since a new project typically needs its own preset built or carefully adapted, and any change to how the manuscript is structured (a new kind of scene break, a different chapter format) can require revisiting Compile settings again.
Avoiding this category of problem entirely
The underlying issue across all of this is that Compile is a separate formatting layer from the editor, applied at export time rather than continuously. A tool where the editor's formatting is the export, with no separate conversion pass to configure, sidesteps the problem rather than requiring careful setup to avoid it. Quillen's export to Word and PDF matches what's on screen exactly, since the manuscript editor only ever renders in the same industry-standard format it exports in.
Common questions
Why does my Scrivener export look different from the editor?
Compile applies its own formatting settings on top of what you see in the editor, based on a compile format preset. If that preset wasn't checked against your project's actual formatting, the exported file can diverge from what you were looking at while writing.
Is there a way to avoid configuring Compile every time?
Saving a custom compile preset once your settings are correct avoids reconfiguring from scratch on future exports of the same project. It doesn't eliminate the initial setup work, and a new project generally needs its own preset built or adapted.