MineralTree (MT) maintains a check sequence number for each payment account in the system (found in Settings>Company Profile>Manage Accounts), which is initially set when onboarding a new account and can be updated at any point. When a check payment is synced to NetSuite, the next number in this sequence is passed back to the accounting system.
NetSuite (NS) maintains its own "Next Check Number" for each bank account, found within the account details (Lists>Accounting>Accounts). By default, this number is equal to the highest check # plus 1.
When "duplicate number warnings" are enabled (Setup>Accounting>Preferences>Accounting Preferences>Items/Transactions) and MT attempts to sync back a check number that is already used, NS will override the check number from MineralTree with its own "Next Check Number." This will cause a mismatch between the check number in MT and NS. Within the same sync cycle, MT will identify the problem, and stop syncing any subsequent payments until the issue is resolved. We actively monitor our logs for this error, and will reach out via a support ticket if this problem occurs.
For example, say the next check number in both MT and NS is 100. If a check is cut in house and recorded in NS, it will be assigned # 100. The next MT check payment will also be assigned # 100, and when this syncs to NS, NS will override this number and assign it #101. MT will stop syncing payments at this point to prevent further mismatches, but we have a case where the same payment is labeled as check # 100 in MT and #101 in NS.
After this problem has occurred, users are faced with the task of reconciling their check numbers and enabling the sync of any payments that may be waiting to sync (see above). To start, we recommend running a bill payment report in NS, which lists every check # by bank account used (via the reports tab or directly from the bill payments list). This can be used to identify any discrepancies between the MT and NS check numbers. To make the NS check number reflect the number that was physically printed on the check, users can either temporarily disable duplicate number warnings and update the NS check numbers to match those of MineralTree or add a unique identifier to the check number in NS (ex. 1013-1 vs 1013). Similarly, users will need to clear the path for any payments awaiting sync from MT (ex. MT check # 200 is awaiting sync but #200 is already used in NS), by either temporarily disabling duplicate number warnings or updating the necessary check numbers in NS. MT support will provide a list of any such payments.
To prevent this issue going forward, we strongly recommend that users set their check sequence in NS to be several orders of magnitude above the check sequence in MT, leaving a large gap between the two. For example, if the highest check number in the system today is 20,000. Set the NS check sequence to 300,000 and the MT sequence to 21,000. Subsequent payments made in NS will use the 300,000+ sequence, and MT will fill in underneath using the 21,000+ sequence, thus eliminating any chance of further check number collisions.