Masav Supplier Payment Files: How They Are Built and What Bounces a Whole Batch

A Masav payment file is a credits file an organisation generates, uploads to the Masav payments site and signs digitally, from which the banks credit beneficiary accounts on the chosen value date. Masav publishes a technical specification for building the file, and every record layout, field length and position must come from there - not from an old sample file circulating in the office.

What happens to the file from the moment it is generated

The process is a chain of four gates, and each has its own class of failure:

1. Generation. Your system produces the file to the specification, including the header and control records and the reconciliation mechanisms the specification defines.
2. Upload to the payments site. Masav scans the structure and flags missing or invalid fields. Structural errors die here.
3. Signature and approval. Authorised signatories approve the run and the value date.
4. Execution at the banks. The organisation's account is debited and beneficiaries are credited. A failure at this stage comes back in a returns file, not on a screen.

The distinction between gate 2 and gate 4 is the difference between "the file was not accepted" and "the payment did not arrive", and those are two completely different investigations.

Why does one bad record reject the whole batch?

Because a payment file is not a list of independent instructions - it is a single unit with control records. An error that breaks the structure or the control totals invalidates the entire file, while an error affecting one beneficiary is handled at row level.

That explains the correct working pattern: prove the structure before sending, rather than discovering it at upload. Four checks worth running locally first:

• Account number validity. Masav publishes account-validity tooling on its support page; checking locally saves a full round trip.
• Hebrew encoding. Beneficiary names in Hebrew are a permanent source of broken characters, which is exactly why Masav publishes Hebrew character tables alongside the specifications.
• Control totals. Record counts and total amounts have to reconcile with the control records the specification requires.
• Duplicates. Same beneficiary, same amount, same value date is almost always a mistake rather than an intention.

The three failure points and where each surfaces

The third row is why the returns file has to be read automatically rather than sitting in a mailbox. Its counterpart on the collections side is covered in reading the Masav returns file and updating customer debt.

Value date, transmission times and business days

The value date is a field the organisation sets, not something derived from the moment of upload. Two design consequences follow, and both are easy to miss.

First, an uploaded file is not an executed file. Between upload and value date there is a window in which the run can still be coordinated with the bank, so any internal report that marks invoices "paid" at upload time is running ahead of reality. Second, the timetable depends on business days and transmission windows that Masav publishes on its support pages - not on the general calendar.

• A run scheduled for a non-business day will not execute that day, which affects the payment terms you promised a supplier.
• Holiday eves and vacation periods shorten the effective window, so a fixed "10th of the month" run needs logic that moves forward rather than backward.
• If the system derives the value date automatically from invoice date plus payment terms, there has to be a step that aligns it to a valid business calendar before the file is built.

The check that prevents most surprises is trivial: display the computed value date on the approval screen, before signature, rather than only inside the file.

What changes when the specification is revised?

Masav's specifications carry a revision date, and Masav publishes notices about changes that require preparation - for example a notice about bank identification codes being retired under a Bank of Israel directive, with a defined effective date. A system that built its file once, five years ago, will not learn about a change like that until the file fails.

The practical preparation is simple: store the specification version the file was built to, assign someone to watch the Masav specifications page, and keep a test path where a file can be checked before a real upload.

How this connects to invoice approval

The payment file should be the output of a process, not its starting point. The order that works: an invoice is captured, approved, matched to an order, checked against a valid withholding certificate, and only then joins a "ready to pay" pool. The payment run takes that pool, builds a file, and produces an exceptions report at the same time.

Skip that stage and the file becomes the place where problems surface that should have surfaced two weeks earlier - a wrong deduction, a duplicate supplier, or an invoice approved twice. The full sequence is described in supplier invoice approval through to a Masav file, and the pre-check in automated supplier verification.

What to have ready before writing the generator

• A valid institution code from your bank, and an active Masav account.
• The current payments-file specification from the Masav site, not a sample file from another system.
• A decision on who is authorised to sign and how that is recorded.
• A mechanism producing a unique reference per payment, so a return can be matched back to it.
• A log of every file sent, including its contents, so you can reconstruct exactly what went out.

Sources

• File specifications and further information - Masav
• Supplier payment management - Masav
• Technical support and downloads - Masav