What Is the Zengin Format? How to Build Japanese Bulk and Payroll Transfer Files (120-Byte Layout)

The short answer: a Zengin file is four kinds of 120-byte lines

The Zengin format (officially the Zengin-kyo standard format) is how a company hands a batch of transfer instructions to its bank in Japan. The files that accounting and payroll software produce with “Zengin data export” or “FB data export” are almost always in this format too. The content is Shift_JIS text, and each line (record) is always exactly 120 bytes, with each field written at a fixed position and a fixed width. It is not comma-separated like CSV, so if a field shifts by even one byte, the bank reads it as a different field.

To pay 30 people, for example, you need 1 header, 30 data lines, 1 trailer and 1 end line — 33 lines, or 33 × 120 = 3,960 bytes excluding line breaks. The bank compares the count and total written in the trailer with its own recount of the data lines, and rejects the whole file if they don't match.

• Numeric fields (N) are right-aligned and padded with leading zeros (account number 123 → 0000123)
• Text fields (C) are left-aligned and padded with trailing spaces
• Only half-width digits, uppercase letters, katakana and a few symbols are allowed. Not a single full-width character may appear
• Because everything is half-width, one character is one byte even in Shift_JIS. The voiced mark ﾞ and semi-voiced mark ﾟ each count as one character

Bulk, payroll and bonus transfers (the type code)

Within the same Zengin format, the kind of transfer is set by the two-digit type code in the header. Paying suppliers and reimbursing expenses is a bulk transfer, employee salaries are payroll transfers, and bonuses are bonus transfers. The layout is almost identical, but the meaning of a few data-record fields changes, as do the bank's fees and deadlines.

You can technically send salaries as a bulk transfer, but many banks treat payroll transfers specially — funds arrive in everyone's account on the morning of payday and fees are lower than for bulk transfers — in exchange for an earlier data deadline. Conversely, mixing contractor payments into a payroll file is normally not allowed under the bank agreement. Keep salaries and contractor payments in separate files.

Header record fields and widths

The header says who is paying, when, and from which account. “Position” counts from byte 1 at the start of the line. When you inspect a file produced by accounting software, cut it at these positions.

The field that generates the most questions is the remitter code. It's a 10-digit number the bank assigns to each agreement; you'll find it in the paperwork from when you signed up for the bulk or payroll transfer service, or in the internet banking admin screen under “consignor code” or “remitter code”. It is not your corporate number or account number, and a made-up value gets rejected at import.

The transfer date is only four digits — month and day — with no year. Even when you prepare payroll data on December 28 for a January 5 payday, “0105” is enough. Picking a bank holiday as the transfer date causes an error or a shift to the next business day, so avoid weekends, public holidays and December 31 – January 3. How to handle dates that fall on holidays is covered in Calculating Payment Due Dates.

Data record fields and widths

There is one data record per transfer, holding the payee's account and the amount. The payee name has only 30 bytes, so long company names may not fit even with abbreviations.

Bank and branch names can usually be left as spaces, because the bank routes the transfer by the codes. Leaving them blank is safer than writing the wrong name. The codes, on the other hand, point to a different bank or branch if a single digit is off, so always check them against the official bank code list or the payment details on the invoice you received.

EDI information lets you attach something like an invoice number to the transfer so the recipient can see it. With the identification flag set to Y, the 20 positions of customer codes 1 and 2 accept half-width letters, digits and katakana instead of numbers only, and the text appears on the recipient's deposit statement. It's used when a customer asks you to put the invoice number in the EDI field to make reconciliation easier. The Zengin EDI System (ZEDI), which carries longer information (up to 140 characters), uses a separate XML format and is a different service from this file.

Trailer and end records, line breaks and encoding

The trailer count and total are easy to forget after adding or deleting data lines by hand. If you delete one transfer but leave the trailer unchanged, the bank rejects the whole file for a count/amount mismatch. Whenever you edit the data, regenerate the trailer as well.

The file encoding is Shift_JIS (code type 0). Since every allowed character is half-width, in practice the file contains only ASCII and half-width katakana. Saving it as UTF-8 turns each half-width katakana into three bytes and breaks the 120-byte boundaries. The most common line-break style is CRLF (Windows) after every 120 bytes, but some banks specify LF or no line breaks at all (records written back to back). Some older specifications also ask for an EOF byte (0x1A) at the end, so if an import fails, check the line-break section of your bank's file specification.

Allowed characters and the rules for half-width katakana

The Zengin character set is very limited. Account holder names are stored in the bank's ledger in half-width katakana, and the payee name is checked against that record, so ignoring the spelling rules can lead to a name mismatch and a recall (kumimodoshi) of the transfer.

• Write small kana as full-size kana: shoji → ｼﾖｳｼﾞ, happy → ﾊﾂﾋﾟ-
• Replace the long-vowel mark with a hyphen: senta (center) → ｾﾝﾀ-
• “Vu” is written ｳﾞ — two characters, because the voiced mark counts as one. Keep this in mind when counting length
• The middle dot becomes a period, and a full-width space becomes a half-width space
• “&” is not allowed; replace it with “.” or similar (match how the bank registered the name)
• Put one half-width space between family name and given name: ﾔﾏﾀﾞ ﾀﾛｳ

Length limits also count voiced and semi-voiced marks as one character each. The payee name slot is 30 characters, but a name with many voiced sounds, such as ｶﾞｸ)ｸﾞﾘ-ﾝﾋﾙｽﾞｶﾞｸｴﾝ, reaches the limit sooner than it looks. Anything beyond the limit is normally truncated, and because banks compare from the beginning, the transfer usually still goes through.

Corporate abbreviations: ｶ) and (ｶ

Company account names are registered with the type of legal entity shortened to an abbreviation — kabushiki kaisha (株式会社) becomes ｶ, for example. The direction of the parenthesis shows whether the abbreviation comes before or after the company name.

Getting the position wrong can trip the name check. Confirm the supplier's official registered name: if kabushiki kaisha comes first, write ｶ); if it comes last, write (ｶ. Even when an invoice says ㈱ or (株), the account name is registered in the abbreviated form. ﾄﾞ for godo kaisha and ｼﾔ for incorporated associations (with the small ya written full-size) are the classic abbreviations people get wrong.

Converting Japan Post Bank account numbers

Japan Post Bank (Yucho) accounts are identified by a 5-digit symbol (kigo) and a number of up to 8 digits, which don't fit the 3-digit branch and 7-digit account fields. To send a Zengin transfer, convert them to the branch number and account number Japan Post Bank defines for incoming transfers. The bank code is 9900.

For a general account with symbol 12340 and number 12345671, the branch number is “23” followed by 8, i.e. 238, and the account number is 1234567 (dropping the final 1). Branch names are kanji numerals such as 二三八店, but you can leave the branch name as spaces. If the number is shorter than usual or it's a transfer account and you're unsure, use the conversion page on Japan Post Bank's website or ask the payee for their “account number for transfers from other banks”.

How to build a Zengin file from Excel or CSV

If your accounting software can't export Zengin data, or a small company keeps its payee list in Excel, converting a table into the Zengin format is the practical route. You can build it with Excel functions (TEXT, REPT, LEFT and so on), but full-width characters and byte shifts are easy to miss, so a conversion tool is more reliable.

1. 1

   Make a table with one transfer per row

   Order the columns as bank code, bank name, branch code, branch name, account type, account number, payee name and amount, followed by customer codes (employee numbers for payroll) or EDI information if needed. The first row can be headings.

2. 2

   Format the code columns as text

   Excel turns “0001” into the number 1 and “0012345” into 12345. Set the bank code, branch code and account number columns to text before typing, or let the conversion tool re-pad them with zeros. Also check that account numbers aren't shown in scientific notation like 1.23E+06.

3. 3

   Enter payee names in kana

   The easiest approach is to type them in full-width katakana or hiragana and convert to half-width katakana at export. If you enter company names in full, including “kabushiki kaisha”, the abbreviation can be applied automatically too.

4. 4

   Keep amounts as plain numbers

   Remove commas and yen signs such as “110,000円”. If the payee bears the transfer fee, enter the amount after deducting it.

5. 5

   Check 120 bytes × lines before sending

   Confirm the exported file size is (number of transfers + 3) × 120 bytes plus line breaks, and that the trailer count and total match your table, then import it into internet banking.

When saving a CSV from Japanese Excel, choosing the regular “CSV (comma delimited)” rather than “CSV UTF-8” saves it in Shift_JIS — but for a CSV you feed into a conversion tool, either works. What you really need to avoid is opening the finished Zengin file in Excel or Notepad and saving over it: the encoding or trailing spaces can change and break the 120-byte records.

Why imports fail and how to fix them

When internet banking reports “invalid file format” or “record length error”, it's almost always one of the following. Checking from the top down finds it fastest.

Sometimes the file is accepted but some transfers come back later (returned or recalled). The cause is nearly always a wrong account number, a closed account, or a large mismatch in the payee name. A recall costs a fee of a few hundred to about ¥1,000 and delays payment, so for a first-time payee, send a small test amount or confirm the account name on the invoice first.

Transfer dates and data deadlines

Sending Zengin data on the transfer date itself isn't always in time. Payroll and bonus transfers in particular have early deadlines, because the bank distributes the data to the payees' banks in advance.

Deadlines are counted in business days, so weekends, public holidays or the New Year break before payday pull them earlier than you'd expect. If payday is the 25th and it's a Monday, three business days before is the Wednesday of the previous week. See How to Count Business Days for counting, and How to Calculate Take-Home Pay or Bonus Take-Home Pay for the employee side of the numbers.

Using the Zengin Format Builder & Checker

With the Zengin Format Builder & Checker you can create and check Zengin files in your browser without memorizing all of the rules above. Account details and amounts are never sent to a server; everything is processed on your device.

1. 1

   Enter the remitter (header) on the “Create transfer data” tab

   Choose bulk transfer (21), payroll transfer (11) or bonus transfer (12), then enter the 10-digit remitter code, remitter name, transfer date and debit account. Turning on the option to save the remitter details on this device saves typing next time (payees are not saved).

2. 2

   Enter payees, or paste them from Excel

   Add them one by one with “+ Add row”, or open “Import from Excel or CSV”, paste a table copied from Excel and press “Import the pasted table” to bring them all in. “Download a template CSV” shows the column order. Codes whose leading zeros were dropped are padded back automatically.

3. 3

   Check converted names and errors

   With automatic conversion of names and bank names to Zengin kana turned on, hiragana, full-width katakana and company names are converted to Zengin half-width katakana with ｶ) / (ｶ abbreviations. Digit counts, invalid characters and amount limits are checked as you go, and any problem row and field is shown.

4. 4

   Match line breaks to your bank and export

   Choose the line break (CRLF, LF or none), whether unused numeric fields are filled with spaces or zeros, and the transfer instruction code, then press “Download the Zengin file (.txt, Shift_JIS)”. The count and total are written into the trailer automatically.

5. 5

   Inspect existing files on the “Check a file” tab

   Open a Zengin file from accounting or payroll software and every record is split into fields, with checks that each line is 120 bytes, that the trailer count and total match, and that no full-width characters are mixed in. “Save payees as CSV (for Excel)” turns it back into a table.

If you only need to fix names, paste them one per line into the “Account name to kana” tab to convert them all to half-width katakana. The position and width of every field is always available on the “Layout reference” tab. Line breaks, how unused fields are filled and which symbols are allowed vary slightly between banks, so compare once with your bank's file specification before your first import.

FAQ

What is the Zengin format?

It's the file layout defined by the Japanese Bankers Association (Zengin-kyo) for handing a batch of transfers to a bank. It is fixed-length text with 120 bytes per line, made of four record types in order: header (record type 1), data (2, one line per transfer), trailer (8, count and total) and end (9). It's used for bulk, payroll and bonus transfers as well as direct debits, and the “Zengin data export” or “FB data export” in accounting and payroll software uses this format.

How many bytes is one line in a Zengin file?

Every record is 120 bytes. Because only half-width letters, digits and katakana are used, each character is one byte in Shift_JIS, so 120 characters = 120 bytes. If even one full-width character slips in, that line becomes 121 bytes or more and the import fails with a record length error. Line breaks (2 bytes for CRLF) are not part of the 120 bytes.

What's the difference between the bulk transfer and payroll transfer formats?

The header type code is 21 for bulk transfers, 11 for payroll and 12 for bonuses. In the data records for payroll and bonuses, customer code 1 is the employee number and customer code 2 the department code, and the transfer instruction code and EDI flag are left as spaces. Banks usually charge less for payroll transfers and deliver the funds on the morning of payday, but set an earlier data deadline — often a few business days before payday.

How is “kabushiki kaisha” written in an account name?

It's abbreviated to ｶ, and the parenthesis shows where it sits: ｶ)ﾔﾏﾀﾞｼﾖｳｼﾞ when kabushiki kaisha comes before the name, ﾔﾏﾀﾞｼﾖｳｼﾞ(ｶ when it comes after, and ﾔﾏﾀﾞ(ｶ)ｼﾖｳｼﾞ when it's in the middle. Yugen kaisha is ﾕ, godo kaisha ﾄﾞ, a medical corporation ｲ, an incorporated association ｼﾔ and a specified nonprofit corporation ﾄｸﾋ.

What happens to small kana and the long-vowel mark in account names?

The Zengin format doesn't allow small kana (ｧ ｨ ｩ ｪ ｫ ｬ ｭ ｮ ｯ) or the long-vowel mark, so small kana are written full-size and the long-vowel mark becomes a hyphen: shoji is ｼﾖｳｼﾞ, happy is ﾊﾂﾋﾟ- and center is ｾﾝﾀ-. Bank account names are registered under the same rules, so following them avoids name-check problems.

How do I write a Japan Post Bank account in the Zengin format?

The bank code is 9900. For a general account (symbol of 5 digits starting with 1), the branch number is the 2nd and 3rd digits of the symbol followed by 8, the account number is the number without its last digit (7 digits), and the account type is ordinary (1). Symbol 12340 with number 12345671 becomes branch 238 and account 1234567. Transfer accounts (symbol starting with 0) use the 2nd and 3rd digits followed by 9 and account type current (2).

Can I turn an Excel payment list into a Zengin file?

Yes. Paste a table with bank code, branch code, account type, account number, payee name and amount columns into a Zengin conversion tool, or load it as CSV, and it is converted into a 120-byte fixed-length Shift_JIS file. Excel tends to drop leading zeros from bank codes and account numbers, so format those columns as text or use a tool that pads the zeros back.

How can I check what's inside a Zengin file?

You can open it in a text editor, but the fields run together without separators, so you have to count positions against the layout table. Opening the file in a Zengin checker splits each record into fields and checks at once that every line is 120 bytes, that the trailer count and total match the data, and that no full-width characters are mixed in. Be careful: saving over the file in Notepad or similar can break the format.

Why doesn't the transfer date include a year?

The transfer date in the Zengin header is defined as four digits, month and day (MMDD), only. Since the data is meant to be created and sent shortly before the transfer date, the bank treats it as the next occurrence of that date. Even when preparing January payments at year end, writing only the month and day, such as “0105”, is enough. Specifying a bank holiday, however, causes an error or a shift to the next business day.