Hashavshevet Import Errors: Build a Rejection File Before You Retry

A journal import that fails partway is more dangerous than one that fails outright, because some rows are already in the ledger. Resubmitting the same file after fixing one line creates duplicate entries instead of clearing rejections. The first move is not to retry: it is to produce the rejection list and reconcile counts and amounts.

Why a retry is riskier than the original failure

Because the file is not an atomic unit. On intake the valid rows go in and the invalid ones are rejected, so the database now holds part of the file. Fix one line, resubmit the whole file, and every row that already landed goes in a second time.

The damage does not surface during the import. It surfaces as a bank reconciliation that will not close, a supplier account showing double the balance, or a VAT report listing documents twice. By then separating the original from the copy is hard, because nothing on either entry distinguishes them.

What belongs in the rejection file

A good rejection file is one you can investigate without opening the accounting system. These fields recover most of the time:

The field teams tend to drop is the source key, and it is precisely the one that makes resubmitting only the rejected rows possible.

Which failures are structural and which are accounting?

That split decides who fixes it. A structural failure is resolved in the code or the file; an accounting failure is resolved in the ledger.

• Structural: a missing column, a wrong date format, the wrong decimal separator, an encoding that mangled Hebrew characters, an amount with a flipped sign.
• Accounting: an account that does not exist, a closed period, a reference number already recorded, debit not equal to credit, an account inappropriate for that entry type.
• Process: the same entry produced twice by the operational system, or a file resent because nobody knew the first one had gone through.

All three categories produce messages that look alike, so it is worth classifying each rejection reason into one of them once, in a mapping table, and reusing it on every import.

The "open new accounts as needed" option and what it costs

On interface intake Hashavshevet checks whether the accounts referenced by each entry exist in the database, and lets you define what happens when one does not. Tick the option that opens new accounts and the software creates the account; leave it unticked and the entry is not accepted and is reported as invalid.

Both settings are legitimate, and each has a price:

• Ticked. The import goes through, but the chart of accounts grows from names that came out of another system. Two months later there are three accounts for the same supplier.
• Unticked. You get rejections, which is exactly what you want on a recurring import - but only if somebody actually reads the invalid-records list and works it.

For a one-off migration import, ticking it is reasonable. For an interface that runs daily, it is usually a mistake.

How do you reconcile a partial import before resubmitting?

1. Produce three numbers from the original file: record count, total debit and total credit.
2. Produce the same three numbers from the entries that actually landed, filtered by batch identifier or intake date.
3. Subtract. The difference must equal the rejection rows exactly. If it does not, a row is counted on neither side and finding it comes before anything else.
4. Correct the source data, not the file. A hand-edited file produces an import nobody can reproduce.
5. Generate a new file containing only the rejected source keys, and submit that.
6. Run the same reconciliation on the new batch, and close the cycle only when the difference is zero.

Designing an interface where a partial import does not hurt

If the interface runs more than once, design it so a rejection is routine rather than a crisis. Three architectural decisions do most of the work:

• A staging table. The data lands first in a table you own, with a status per row: pending, accepted, rejected, under review. The import file is built from there, not directly from the operational system.
• A batch identifier. Every run gets a unique identifier stamped on every row. Without it there is no answer to "what exactly went in yesterday at three".
• A uniqueness key. A combination of source key and entry type that prevents double intake even when somebody runs the same file by mistake.

The practical benefit is that corrections happen in the staging table rather than in a file. A rejected row is fixed, returns to pending, and the next run picks it up alongside the new ones. Nobody hand-edits a text file, and nobody submits the same file twice.

What to keep once everything has gone through

A successful import is still an event that has to be reproducible. Keep the file as it was submitted, the batch identifier, the three control totals, the rejection list and the response file. When the accountant asks six months later where a particular entry came from, that is the answer.

This is a technical description of an import and control process, not accounting advice. How entries should be recorded, and which requirements are binding, is a question for your accountant.

Related: integrating with the Hashavshevet API, automating Hashavshevet and Rivhit, a daily bank reconciliation process.

Sources

• Importing accounts and journal entries from a file - Hashavshevet Cloud guide
• Automatic data import into Hashavshevet - vendor documentation