Bank Reconciliation Corrections in Auditor
Bank Rec Ending Date
In the back end, go to Tables / BankRecs. The Date column is the date the reconciliation was completed in Jewel. A Date of 1/1/1990 is assigned to Beginning Balances. A Date of 12/1/1994 is assigned to bank recs that have been "undone".
Correct the EndingDate column of the bank rec(s) that are incorrect.
Bank Rec Beginning Balance
Jewel uses the ending balance for the previous bank reconciliation as the beginning balance for the next bank rec. "Previous" is defined as the first-completed bank rec on the latest possible date. This can cause problems when treasurers accidentally save reconciliations with future ending dates and then try to correct the problem themselves.
If a beginning balance is incorrect, compare the Date column to the EndingDate column to ensure that everything makes sense. There shouldn't be any Ending Dates that are after the Date of reconciliation, such as the 4/30/26 reconciliation done on 4/7/26. And there shouldn't be any duplicate Ending Dates. If you find an error or duplicate, simply type in the correct Ending Date. Duplicates can be separated by changing the date by one day, so you have 4/29/26 and 4/30/26 instead of two 4/30/26's. This also resolves a known issue with the Bank Rec report, where only one reconciliation per date can be viewed.
Cleaning Up the Bank Rec in Auditor
Clearing old transactions out of the bank reconciliation is essential to generating correct reports. Generally, eposits, transfers, and electronic payments over a month old should be investigated and cleared, as should checks over about six months old. Start by reading Cleaning Up the Bank Rec in the Jewel Handbook.
Stale Date Checks and Electronic Payments
By the time tech support gets involved, outstanding checks are often several years old, so can simply be voided and cleared, without any real need for investigation. The exception is remittance checks, see below.
If the treasurer is frequently entering duplicate checks or electronic payments, they may need help finding a better system.
Stale Date Remittance Check
Stale dated remittance checks must be handled with care, because if they are voided, Jewel will reverse the check and add the "unpaid" remittance to the next remittance check. This may occasionally be appropriate, but usually remittance checks end up with stale dates because they were duplicated in Jewel.
Duplicate Remittance Checks
When you see an old, uncleared remittance check, always check to see if it's a duplicate. Usually, the duplicate check will be entered early in the next month, and written out of local funds. To look for duplicates, go to Reports & Graphs / Check, choose a large date range around the date of the remittance, and sort by Payee. Another option is to go into the back end, to Tables / JournalItems, and sort by amount. Note the JournalIDs of the duplicate entries (not the JournalItemID, but the JournalID), then go to View Journal and find the specific transactions. The JournalID is shown in the left-hand column when you hover over it with the mouse.
Once you have found both checks, ensure that the correct check, the one written out of conference funds, got cleared on the bank reconciliation, and the check written out of local funds is marked outstanding (see section on Marking Transactions Cleared/Uncleared). Then you can void the outstanding check.
Non-duplicate Remittance Checks
If the stale-dated remittance check is not a duplicate, more research will be needed. Two options are to check bank statements to see if the check cleared, or contact the conference office to see if the check was received. For Jewel tech support, use your judgement regarding whether you do the research yourself or if you ask the treasurer to handle it and get back to you.
If the remittance funds are still owed to the conference, then the stale-dated check should be voided. Jewel will automatically add the unpaid funds to the next remittance submission. Tech support can re-send an ACH request (see below). Or, if the conference prefers, treasurers can go to Accounting / Make Manual Remittance and write a paper check to replace the stale-dated check.
To re-send an ACH request, use Auditor to open the month whose remittance report needs to be re-sent, with the NextStep button set to Remit to Conference. Go to Accounting / Void a Check, and void the remittance check for that month. (The reason for voiding the original check is that, generally, it saves editing the remittance check.) Click Remit to Conference, and verify that everything on the check is correct. If it's not, click Edit Check and fix it. Click OK, then click the NextStep "Send Remittance Report" and confirm.
If the remittance funds are not owed to the conference, then void the stale-dated remittance check, and Transfer Funds from the affected conference funds into a local fund like Church Budget. Obviously, since tithe funds are sacred, this should only be done when you are very sure that the funds really weren't owed, and with the support/approval of the conference office. Also be sure to use the memos on the transfer and the voiding transaction to connect the transactions for an audit trail.
Offering Deposit
Stale-dated offering deposits are often duplicate entries. Often one entry is near the end of the month, and the other is near the beginning of the next month. To look for duplicates, go to Reports & Graphs / Deposit, and choose a large date range around the date of the outstanding deposit. Another option is to go into the back end, to Tables / JournalItems, and sort by amount or search for the amount. Note the JournalIDs of the duplicate entries (not the JournalItemID, but the JournalID), then go to View Journal and find the specific transactions. The JournalID is shown in the left-hand column when you hover over it with the mouse.
If you confirm that the deposit is a duplicate, then it can be deleted, reversed one envelope at a time, or reversed with a General Journal Entry. Which option you choose will depend mostly on how long ago the duplicate happened. Deleting is by far the easiest option, and is appropriate when the duplicate happened recently. If the deposit is old enough that donor receipts have already been issued and examined by the donors, then reversing with a General Journal may be appropriate, since it's a lot easier. But if the deposit is in that magical "too old to delete, but new enough that people want a correct receipt" range, then it must be reversed with a negative offering deposit, envelope by envelope. As always, use your best judgement.
If the offering deposit is not a duplicate, it still needs to be reversed as above. But now you have to worry about why there's a deposit that never made it to the bank. Jewel tech support may report questionable activity to the conference office, but is not under obligation to do so.
Transfers and General Journal Entries
The basic idea for these transactions is to manually enter a reversing transaction. Always write a good memo so the auditor can follow what happened.
Outstanding transfers between bank accounts should be thoroughly investigated, as treasurers often enter these incorrectly. The usual incorrect method is to write a check out of one account (from a local fund), and then deposit the money into the other account (into a local fund). Sometimes the local funds aren't the same on both ends. And sometimes only the check or only the deposit gets entered. The deposit might be included in an offering deposit. So verify that a) the funds didn't get unintentionally moved from one local fund to another, and b) both bank accounts show the correct balance. Use Transfer Funds and/or Make General Journal Entry to get everything where it belongs. And as always, write good memos, referencing original dates and transaction numbers, to preserve an audit trail. Encourage treasurers to use Transfer Funds or Transferring by Writing a Check in the future. They often also need help understanding why transferring funds from Savings doesn't increase local funds.
Transaction Cleared on Wrong Bank Rec
To clear a transaction on a specific bank reconciliation, click Auditor to get into the back end. Go to View Journal and select the transaction. Note its JournalID by hovering over the left-hand column. Then the BankRecID column at bottom left gives the number of the bank reconciliation the transaction is currently cleared on, but cannot be edited.
Go to Tables / BankRecs and find the BankRecID of the correct bank rec, using the Ending Date and AccountID. If necessary, go to Tables / Accounts to find the correct AccountID. Remember you can sort by clicking on column headings, so clicking on the Name column sorts the accounts alphabetically.
Finally, to edit the BankRecID, go to Tables/JournalItems, find the affected transaction by its JournalID, make sure you're on the line with the correct AccountID, and type the number of the correct bank rec under ClearedBankRecID. Or if a transaction should not be cleared at all, delete the bank rec ID.