You could first take a look at where are you seeing a 'mismatch' in the number of documents, ie, is it in the Archive Log, the Notes Status Bar, etc.

Then confirm what your Archive Criteria settings are used for scheduled archiving, and confirm what your expectations are for documents that would/should be handed by archiving process from the application in focus.

And finally, take a look at the following to help determine whether an archive preference might be of impact to your result,

http://www-01.ibm.com/support/knowledgecenter/SSULMR_9.0.0/client/set_archive_prefs_t.dita?lang=en

For instance, you can also choose not to delete documents that have responses if the responses have been modified during the time you specified so that a parent document is not deleted, leaving orphaned responses in your application.  Once the final child/response document meets the archive criteria you have defined, then the parent is simply deleted from the source application.

You could then take a look at the document properties of the document you expected to be archived and confirm whether: it was updated recently and would not match the archive criteria you have specified; is a parent document that still has an existing child/response document in the application; or, in case that all child/response documents have been archived, whether no changes were made to the parent and it was just deleted since it was already copied/archived to the archive database to maintain parent-child relationship for docments within the archive.

If after review of these areas you find you might still have questions, then you can try adding some client debug to output archive logging and see how archive process is handling specific documents, and from there witness whether or why a document may not match the criteria you specified, http://www.ibm.com/support/docview.wss?uid=swg21313174.  You may prefer to output this debug to a separate file, using debug_outfile= , or include console_log_enabled=1 to add it to the console log file within your Notes\Data\IBM Technical Support folder.  Add either of these parameters to the client's notes.ini file along with your log_archiving parameter and retry the scheduled archive event.

Should you have additional questions or require more immediate assistance in review of an application and result debug output obtained, you may prefer to open a pmr with us and simply attach those files so we can take a look at them futher with you.

You should look at the replication settings to ensure that you do not have any replication formulas in place, also, if you wish to troubleshoot, you can use the LOG_Replication=4 and have console logging enabled.  Perform a replication between the two servers, and check the console log to see wht failed to replicate properly, and why.

Since the Archive process is done at the server end using Compact command and not locally, and sounds like Archiving works without concern, then you can probably focus more directly on the aspects that might impact replication of data or for the application itself.

In general, 'if you cannot see it, you cannot replicate it'.  If upon review for formulas, as Bradley suggests, you do not find the immediate cause of the result, you can try taking a look at the application and what content or overall accesss the servers in focus might have on it.  Possibly the difference in content is being caused by what servers have access to for replication.  We would ask that you review areas that might be helpful, such as: Application acl, Readers/Authors fields, design elements, template, etc