Submitting a research paper to a conference or journal can be a stressful process; there are many things to remember, and mistakes can have dire consequences. Here is my attempt to summarize all the steps and my experience about some points, because it's easier to follow a checklist than to remember every time what you have to do. Note that I'm making some implicit assumptions, e.g., that you are using a revision control system, that you are using LaTeX, etc.; also, this list may not be sensible or exhaustive in all fields (I'm talking from the perspective of theoretical computer science).

TODO flushing.

There should be no tasks left before you start finalizing the submission. Of course, it's fine to remove a TODO because you decided to not do it because you did not have the time, the energy, it wasn't worth the effort, etc.; but the status of all TODOs must have been cleared, so you won't realize after proofreading that there were some changes left that you intended to do. Possible sources of TODOs to process:

• In the main text: those should be the most obvious.
• In LaTeX comments: I don't use those but some people do, consider grepping for "TODO" or such keywords (for this reason, TODOs that you gave up on should probably be moved to a separate file, not just commented out)
• In a separate TODO file: did you start jotting down things to do in separate files ("TODO", "ideas", "meeting_notes")?
• In your mailbox: if you have any mail in your inbox about the submission, you probably intend to get rid of it once submitted, so go through it before you start finalizing, and ensure nothing is left to do.
• In the reviews of a previous unsuccessful submission of the paper.

Once the only task left is "proofread the submission", you can continue.

Proofreading.

Go over the submission once, linearly, from start to end. You may want to do it on screen, or on paper (annotating the paper copy and then implementing any changes). If using a WYSIWYM editor such as LaTeX, when editing anything during proofreading, it is crucial to recompile and read again what you just changed, preferably the whole paragraph: fixing errors can easily introduce other errors, and you won't be proofreading again what you are currently changing.

Hopefully, at this point, the scientific content of the submission should not change. If it turns out you have to make significant fixes when proofreading, consider doing a second proofreading pass.

Check that you proofread the following, which are easily forgotten:

• Paper title, author information: especially affiliations, which are often filled in casually early on and may not be sensible.
• Section titles in the paper: go once through the paper looking just at section titles, to check that they make sense and match the "Paper structure" paragraph if you have one.
• Footnotes.
• Floats, figures, algorithms, etc.
• Formal statements: it's easy to focus on the prose, but you should double-check that the precise wording of theorems makes sense, no matter how they are framed.
• Bibliography: Do all references follow the same format? Are you consistent when abbreviating venue names? when including or discarding page numbers, addresses, publishers? Are all author names sensible? Are all acronyms and proper names correctly capitalized in titles (e.g., no "Designing an xml language for hadoop")?

Once you are done proofreading, you have a known good version. It may make sense, when doing further changes, to check their diff against that version to spot any errors that you would be introducing.

Spellchecking.

Use any spellchecking tool. Also check for notations and terms and other things that shouldn't be there anymore:

• Remove the definitions of macros that should no longer be used (for old macros, for TODO notes, etc.)
• If you introduced a macro to replace a notation and changed the notation, check for hardcoded instances of the notation or of previous notations.
• If a name has multiple variants and you have been using them inconsistently, standardize to one name (e.g., "foo bar" to "foo-bar"). When looking for occurrences of multi-word names, don't forget that there may be a line break in the middle (i.e., check for "foo" at end of line).

Typography.

Check for the following:

• Math identifiers at the beginning of lines: if "of x" is split, make the space between the words non-breaking.
• Overfull \hboxes: check for them in the LaTeX log and fix them by rewording, or tweaking hyphenation for technical terms that LaTeX does not know.
• General page layout: widows and orphans, spacing around environments and floats, positioning of section titles (not at the bottom of a column!), placement and numbering of floats, etc.

Sanity checks.

Verify the following one last time:

• Go through the call for papers and formatting instructions:
  • Did you get the page limit right? Including or excluding references?
  • Are you using the correct style file? Are the font size and paper size correct?
  • Should you be including author information? (depends if the venue is double-blind or not)
• Search a last time in the PDF and grep in the source folder for bad strings like "TODO", "FIXME", and other such stuff.
• Check the LaTeX log for bad errors like broken references or multiply-defined labels. Search for "??" in the PDF to double-check that there are no broken references.
• Will you be submitting your LaTeX source? If yes (e.g., on arXiv), make sure there are no embarrassing comments left in the LaTeX. See for instance the script in this arXiv FAQ entry. In addition to comments, do you have block comments with iffalse, the comment environment, or custom commands? Are some of the LaTeX files unused, i.e., not included in the compilation?
• Are all your changes committed to the revision control system? Check this on all the machines where you have been editing the document (to make sure that there aren't uncommitted changes on a different machine).

Submitting.

Submit the paper. Check the following:

• Are the title, author information, track, keywords, etc., correct on the submission interface?
• If you had to indicate conflicts of interest, did you do it?
• Are you supposed to submit additional things, like uploading an appendix elsewhere? If yes, don't forget them.
• Update the abstract on the submission interface.

Double-checking.

Re-download the file that you submitted from the submission interface and go through it to check that it looks good.

• Are all pages there?
• What is the last change that you did? Is it there?
• Did you submit the right file, for the right paper? This may sound stupid, but strange things happen at 5 AM. It is especially important if you have multiple submissions for the same deadline.

It's normal to find mistakes at the last minute when going over the PDF after submitting. Of course, when fixing them, be extra careful; at this stage you should probably be double-checking the changes that you make, and checking them again by proofreading the diff before you commit.

Concluding.

Decide you are done.

Let your coauthors know. Thank them for their hard work.

Then, celebrate as you see fit. :)

Aftermath.

The following are things that you should probably do, but there's no urgency in doing them, so the safest way to avoid doing them multiple times because of last-minute fixes is to wait for the deadline to be over.

• Ensure that your version control system knows what was the final submitted version.
• If applicable and not double-blind, upload your preprint on your website and/or a preprint repository such as arXiv.