Reportingadvanced
BI Publisher eText Templates for EDI/Fixed-Width Output
Explain how BI Publisher's eText template type generates fixed-width and delimited output for EDI and banking integrations
A bank does not read a PDF. It reads a file where each field occupies exact byte positions. eText is the BI Publisher template type that produces those.
eText is like a form used for optical character recognition scanning where every box must be filled in a precisely defined position — unlike a flexible handwritten note (RTF/PDF layout) where slight variations don't matter, this format requires exact positional discipline because the receiving machine (bank's parsing system) reads by rigid position, not visual interpretation.
Key Concepts
1
The difference from an RTF template.
RTF template how it looks. Spacing is cosmetic.
eText template where every byte sits. Position is the contract.2
A payment file with the amount one character out is rejected by the bank's parser, or worse, misread.
3
An eText template is built in Excel, with command rows controlling the file and definition rows
describing the fields:
4
<LEVEL> PaymentHeader
<POSITION> <LENGTH> <FORMAT> <PAD> <DATA>
1 1 Alpha ' ' '5'
2 9 Number '0' CompanyId
11 16 Alpha ' ' BatchName
27 10 Number '0' TotalAmount5
Each row says where the field starts, how long it is, what pads it and whether it is left or right aligned.
Numbers are usually zero-padded and right aligned; text is space-padded and left aligned.
6
Records nest. A payment file is a file header, then batch headers, then transactions, then trailers with
counts and totals — and the template expresses that hierarchy, with the trailers computed from what came
before.
7
Where it is used. EFT and wire payment files from EBS Payments, NACHA for US ACH, and EDI transaction
sets. Anywhere a receiving system parses by position rather than by tag.
8
Why you cannot use an RTF template for this. RTF produces a visual document. Even exporting it as text
gives you spacing that looks right and is not guaranteed byte for byte, and no control over padding
characters or numeric formatting to a fixed width.
9
The practical note. The specification comes from the bank or the trading partner and is exact. Building
one of these is transcription against a document, and testing means the receiving system accepting the file
— not it looking correct.
10
Most defects here are a field one position out, or a number padded with spaces where the specification says
zeros. Both produce a file that looks fine and is rejected.
11
What the interviewer is probing.1. "What is an eText template for?" Probing: the fit. Stalls: "Text files." Moves up:
generating fixed-position or delimited files to an external specification — EDI, bank payment files,
regulatory submissions.
12
2. "How does it differ from an RTF template?" Probing: the distinction. Stalls: "Nothing."
Moves up: it is a table of field definitions with position, length, format and padding rules,
rather than a visual layout.
13
3. "What is the usual source of defects?" Probing: experience. Stalls: "Logic." Moves up:
padding, alignment and character encoding — a bank rejects a file for a trailing space, not for
wrong business logic.
14
4. "How would you test one?" Probing: the method. Stalls: "Send it." Moves up: byte-level
comparison against a known-good sample from the receiving party, before anything reaches them.