In my experience with off-the-shelf and bespoke accounting systems in the US, sequential numbers are not required by accountants or auditors. What is required is a demonstration of controls and auditing capability. If an item is deleted, there has to be a trail. The detection of a deleted item is not tracked by a missing number - after all, there are other kinds of tampering to get around requiring sequential numbers, and a demonstration of adequate controls goes far beyond that.
However, I have seen such a requirement in Mexico for reimbursement from the governent. I believe they use it to avoid fraud for multiple submissions to the state agency. IMO, it's not an effective internal control, and has limited scope for catching fraud in the third-party interaction situation.
In general, using an increasing integer id (like IDENTITY) (or GUID - but normal GUIDs are not increasing like that) as a surrogate primary key in tables and clustering on that helps improving SQL Server performance. Note that it is possible for an IDENTITY value to be used up but a transaction to fail or be rolled back, leaving a gap. This gap will not be normally filled in (although it could be by using identity insert).
Here's some COMB ID links:
http://jeffreypalermo.com/blog/use-guid-comb-in-your-database-if-you-need-guid-keys-but-don-t-want-to-take-a-big-performance-hit/
http://www.informit.com/articles/article.aspx?p=25862
We actually modified it a little, used them with CSLA and called them SmartGUIDs. The SmartGUID class exposed a creation date property. Unfortunately, I'm no longer affiliated with that project or company, so I don't have access to the source code to recall our technique exactly.