DEV Community: ARLing

Lectio divina journal for reMarkable and Kindle Scribe: the Douay-Rheims text on the page, and room for the pen

ARLing — Fri, 25 Sep 2026 08:29:59 +0000

Originally published at https://arling.sk/notes/lectio-divina-journal-remarkable-kindle-scribe-douay-rheims/

Lectio divina journal for reMarkable and Kindle Scribe: the Douay-Rheims text on the page, and room for the pen

A devotional PDF for an e-ink tablet is usually a set of ruled pages with a field for a Bible reference: you bring the text. Morning Quiet, Book 1, goes the other way round. Each of its 31 days has the text of one Psalm and one Gospel passage from the Douay-Rheims Bible printed on the page, followed by four steps of lectio divina with lines for the pen and an evening examen with three questions. The book is set for a screen: a 157 x 210 mm page, the 3:4 shape of a 10.3 inch e-ink display, so a page fills the reMarkable 2, the reMarkable Paper Pro, the Kindle Scribe and Boox readers of that size without bars at the sides. The numbers in this note are measured in the finished file, not promised: 214 pages, 592 internal links, 71 link targets, 0 dead. Page 1 is the cover, and every ruled writing line in the book is a real PDF form field. It ends with what we have not verified, because nothing has been opened on a physical device yet.

What is on the page each day

The morning page begins with the Our Father, then the Psalm and the Gospel passage in full, then the four steps of lectio divina in the order Guigo II set down in The Ladder of Monks: lectio, meditatio, oratio, contemplatio. Lectio has no lines, Meditatio has 3 lines, Oratio fills the rest of the page with lines 8 mm apart and Contemplatio has no lines. Beside the reading is a 39 mm margin for notes with the pen. Every one of those ruled lines is a PDF form field, 1038 of them on 118 pages: you write on them with the pen on an e-ink tablet, or type into them on a computer in Adobe Acrobat Reader, Preview or Firefox.

The evening page is an examen with three questions of our own and lines under each: what am I thankful for today, where did I meet God and where did I turn away, what do I want to do differently tomorrow. It is a short editorial form of the examination of conscience Saint Ignatius of Loyola describes in the Spiritual Exercises, not an official text.

Psalms carry both numbers, for example Psalm 23 (22): the Hebrew number first, the Douay-Rheims and Vulgate number in brackets; from Psalm 10 to 147 they usually differ by one. Book 1 covers Psalms 1 to 31 in the Hebrew numbering, with Psalm 18 over two days and Psalms 9 and 10 on one day because the Vulgate counts them as one, and Matthew 1 to 12.

The days are numbered 1 to 31, with no year and no weekday and a line for your own date on each morning page. Days 7, 14, 21 and 28 are written for Sunday, the Lord's Day, each with a page for the week, and a fifth week page closes days 29 to 31; start on a Monday and the Sunday pages fall on real Sundays.

Where the words come from

The Scripture text is the Douay-Rheims Bible, Challoner revision (1749 to 1752), American edition of 1899, which is in the public domain. The book follows the digital edition of eBible.org, ID engDRA; only the markup is removed, and the annotations of the printed edition are not included. Psalm and verse numbers follow the Vulgate.

That digital edition has obvious transcription errors, and Book 1 corrects 12 of them, for example Manesses for Manasses in Matthew 1:10, but only where two other transcriptions of the same printed edition, drbo.org and Project Gutenberg ebook 1581, agree on a different reading. The list of corrections is on the last page of the book. Of the 828 verses in Book 1, after the corrections 652 are identical with the Gutenberg transcription, 99 differ only in punctuation and 76 differ in wording without an obvious error; those 76 are left as they are.

The framework text, that is the headings, instructions and questions, is editorial text of ARLing prepared with AI assistance and approved by the publisher, and the typesetting is done by our own program.

Three files, and the links measured in them

Book 1 is three PDF files of 214 pages each: an e-ink file with a 157 x 210 mm page and no page numbers, and A4 and US Letter files that centre the same 139 x 194 mm page block on the sheet and add a page number, so the pages, their order and the links are identical in all three. One day is 5 to 10 pages; the smallest type in the file is 10 pt and the reading text is 13 pt. Page 1 of each file is the cover, and the form fields are added to the finished PDF by a script that checks that the drawing of every page is the same before and after and that the number of links did not change, 592 before and after.

The check script counts 592 internal links and 71 link targets in the e-ink PDF, 0 dead links and 0 links leaving the document. The contents page carries 36 links, the Day 1 morning page 4 and its evening page 3. These are ordinary links in HTML, and Chrome keeps them when it prints to PDF, as Link annotations with a destination inside the same file, which is why they travel with the file to the tablet.

The navigation buttons sit in a centred bar at the bottom of each page, measured in the e-ink PDF at least 29 mm from the left and right edges and 15 mm from the bottom edge, away from the edge zones that some readers reserve for gestures. On e-ink tablets links are usually tapped with a finger, not the pen.

Getting the file onto the reader is the same as with any other book: download the PDF on a computer or phone and copy it over with the reMarkable desktop or mobile app, Send to Kindle for the Scribe, or a USB cable and the device folder for Boox. Nothing is installed and no account of ours is needed.

What we have not verified

The file has not been opened on a physical reMarkable, Kindle Scribe, Boox or Supernote. The link margins are measured only in the PDF, and readers differ in how they handle internal links and in which edge zones they keep for gestures. The ruled lines for the pen are 0.3 pt grey, and whether they are visible enough at 226 dots per inch is untested.

That is why there is a free sample: days 1 to 7 as a separate PDF of 52 pages with 139 internal links, 0 dead, the same 157 x 210 mm page and the same kind of links as the book, with 229 of the same form fields on 26 pages. If a link does not respond on your device, you know before you pay.

FAQ

Is the Bible text in the book, or do I need my own Bible?

The text of each Psalm and Gospel passage is printed on the page, from the Douay-Rheims Bible, Challoner revision, American edition of 1899, in the public domain. Book 1 covers Psalms 1 to 31 in the Hebrew numbering and Matthew 1 to 12.

Is this an approved liturgical book?

No. It is a private aid to prayer, not a liturgical book; it does not replace the Mass, the Liturgy of the Hours or spiritual direction, and no ecclesiastical approval is claimed.

Which devices is it made for?

The e-ink page is 157 x 210 mm, the 3:4 ratio of the reMarkable 2, the reMarkable Paper Pro, the Kindle Scribe and Boox readers of that size. We have not tested it on a physical device, so try the free sample of days 1 to 7 on yours first.

Where to get it

The free sample of days 1 to 7 is on the Morning Quiet page, with no account and no e-mail. Book 1 is sold as a digital download in our Etsy shop, https://www.etsy.com/shop/ARLingPuzzles, for 4.90 €: the e-ink, A4 and US Letter files and the sample as a fourth file. Our other titles for the same page size are on the puzzle books page: ten printable puzzle books of 100 puzzles each, 4.90 € a book.

ARLing also publishes printable puzzle books.

Hyperlinked puzzle PDFs for reMarkable and Kindle Scribe: what changes when the contents page is tappable

ARLing — Thu, 24 Sep 2026 08:31:43 +0000

Originally published at https://arling.sk/notes/hyperlinked-puzzle-pdf-remarkable-kindle-scribe/

Hyperlinked puzzle PDFs for reMarkable and Kindle Scribe: what changes when the contents page is tappable

A puzzle book on an e-ink tablet is a PDF, a stack of pages with no index behind it, so a puzzle near the end is a long swipe away and its solution is somewhere at the back. A tappable contents page removes that swipe. In our e-ink layout the page right after the rules is a Contents page: tap a number and that puzzle opens, and every puzzle page carries a Solution link to its own solution and a Contents link back. The page itself is built for the screen rather than for paper: 157 x 210 mm, the 3:4 shape of a 10.3 inch e-ink display, so a page fills the screen without bars at the sides. This note covers the page size, the layout behind it, what the links do in all three files of an edition, and how the file gets onto a reader.

The page is a screen, not a sheet of paper

The reMarkable 2 and the reMarkable Paper Pro both have 1404 x 1872 dots, which at 226 dots per inch gives 157.8 x 210.4 mm, and that is where the 157 x 210 mm page comes from. The Kindle Scribe with 1860 x 2480 dots and Boox readers of that size have the same 3:4 ratio, so the same page sits on those screens as well.

That single decision is what keeps the grid large: a page cut for A4 and shown on a 3:4 screen is letterboxed, and every millimetre of that band is taken off the puzzle.

What changes on the page when nobody prints it

Nothing is bound and nothing is trimmed, so the 8 mm margin is the same on all four sides and does not alternate between left and right pages. There is one puzzle per page even on a small grid, because you page through a reader whole screens at a time. The cell ceiling goes up from 22 mm to 30 mm, because you write into it with a stylus rather than a pencil. Solutions go four to a page instead of six, page numbers are dropped because the reader pages itself, and the lines get stronger contrast for a display with sixteen shades of grey.

The contents page and the two links on every page

The contents page lists every puzzle number as a link, grouped by level. From a puzzle page, Solution jumps to that puzzle's answer and Contents jumps back to the list; from a solution, one link goes back to its own puzzle.

These are ordinary links in HTML, and Chrome keeps them when it prints to PDF, as Link annotations with a destination inside the same file. The test of a 300 puzzle book counts 379 pages, one of them the Contents page, and 300 links back to the contents.

Three files, one puzzle set

An e-ink edition holds 300 puzzles in three levels, 100 easy, 100 medium and 100 hard, with the solutions at the back. The finished Voles E-ink edition has three PDFs of that same set: the e-ink file with 379 pages on a 157 x 210 mm page, an A4 file with 304 pages and a US Letter file with 304 pages, and the PDF check passed on all three.

In an e-ink edition the builder puts the links into the A4 and US Letter files as well, so tapping works in all three; older catalogue editions meant for print stay without links, so published files stay unchanged.

Every puzzle was built and solved by our own program and kept only when the solver found exactly one solution, and that solution is the one printed at the back.

Getting the file onto your reader

Download the PDF on a computer or phone and copy it to your reader the way you normally add a book: the reMarkable desktop or mobile app, Send to Kindle for the Scribe, or a USB cable and the device folder for Boox. Nothing is installed and no account of ours is needed.

FAQ

Do the links survive the transfer to the tablet?

They live inside the PDF as Link annotations pointing to a destination in the same file, so they travel with it. A reader that opens PDF links follows them; one that does not still shows every page, and the contents page is a printed list of numbers as well.

Why 157 x 210 mm and not A4?

Because a 10.3 inch e-ink screen is 3:4, the same ratio as 1404 x 1872 dots at 226 dots per inch, so a 157 x 210 mm page fills it without bars at the sides. The A4 and US Letter files are in the same edition for anyone who prefers paper.

Are the e-ink editions on sale already?

Not yet. As of 17 September 2026 the e-ink editions of all ten games are built locally and not published, with a planned price of 4.90 € for 300 puzzles. What you can buy today is the printable range.

Where the books are now

The ten puzzle books on our puzzle books page hold 100 puzzles each, with a PDF for A4 and one for US Letter; a single book is 4.90 € with VAT included and all ten together are 19.90 €. The e-ink editions with 300 puzzles are built and waiting, not published yet.

ARLing also publishes printable puzzle books.

Dormice: a daily logic grid puzzle you solve from the clues alone

ARLing — Wed, 23 Sep 2026 08:29:59 +0000

Originally published at https://arling.sk/notes/dormice-daily-logic-grid-puzzle/

Dormice: a daily logic grid puzzle you solve from the clues alone

Dormice is a daily logic grid puzzle. Every dormouse in the copse keeps one store in one tree, and in the bigger puzzles wakes in one week of the spring; there are as many stores, trees and weeks as there are dormice, and no two dormice share any of them. One store went missing from the shared larder overnight, and when the table is full the last line tells you who had it, where and when. Every numbered clue beside the grid is true, and the clues together leave exactly one way to match everything up. Nothing has to be guessed, because every square can be reached from the clues by reasoning. This note covers what a first grid hides: the notepad, the tick that fills a row and a column, the carry between tables, the auto cross switch and the week of levels.

The grid is a notepad, not the answer

The grid is your notepad. Each small square joins one item on the left with one item above: a cross when you know the two do not belong together, a tick when you know they do. Two marks carry the whole puzzle.

The board is a staircase of small tables, with dormice against stores, stores against trees and, in the bigger puzzles, the weeks as well. It stops at twelve columns on purpose: at 390 px of screen a square is then about 29 px across, above the 24 px a finger needs.

One tick, and the rest of the table follows

As soon as a tick goes into a square, every other square in that row and in that column of the same small table is a cross, because each item belongs to one dormouse and to no other.

Ticks also carry from table to table. If Pip keeps the sloes and the sloes are in the elm, then Pip woke in the elm, and anything the sloes are not, Pip is not either. The clue you need is often not about the pair you are looking at.

Order clues work on the week column: the weeks run in order, one week apart, so two weeks earlier means exactly two steps along that column, and earlier without a number means any number of steps.

Auto cross is on, carry across is off

After a tick you would write in crosses for a while, and with four categories of four items that is 72 crosses for 24 ticks, which is bookkeeping rather than deduction. Auto cross fills them in and is on by default, a recorded deviation from our own controls standard where automatic helpers are off; the whole filling is one step in the Undo history and the switch sits in Settings.

Carry across, the transfer of consequences between tables, stays off by default, because that step is a deduction you have not seen yourself.

Monday is easy, Sunday is not bigger but harder

Monday and Tuesday are easy: three categories of five, no weeks, clues that match or rule out a pair outright. Wednesday and Thursday are medium, four categories of four, with the weeks and the first order clues. Friday and Saturday are hard, the same shape with at most one outright match. Sunday is the challenge: no outright matches, and one square that gives way only when you test an assumption until a clue breaks.

Hard and Sunday are not bigger than Wednesday, they are harder, and that order is measured: the solver counts how many steps of each kind a finished puzzle needs, and the candidates for a date are ranked by that number.

Free archive, practice sets and a hint that stops

Hint and Check both work in two steps and are free. The first press of Hint names the technique and the table without the value, the second fills in exactly one square and stops there; the first press of Check says how many of your ticks are wrong and which table they are in, the second marks them, and nothing turns red while you play.

The practice sets hold twenty four copses with no date attached, three sets of eight for each level, and the archive holds every daily copse since 10 September 2025, free; your own times and hints stay in your browser.

FAQ

Do I ever have to guess in a Dormice puzzle?

No. A copse is only used when a person can finish it with human rules without guessing, and a second independent search confirms that exactly one answer exists.

What is the difference between auto cross and carry across?

Auto cross writes in the crosses a tick forces inside its own small table, which is counting rather than deduction, so it is on by default and undone in one step. Carry across moves consequences between tables, a deduction you have not made yourself, so it stays off until you turn it on.

Is the Sunday puzzle bigger than the rest of the week?

No, it is harder. Wednesday to Sunday all use four categories of four; Sunday simply has no clue that matches two items outright.

Pick today's copse on the games page

Open the ARLing games page, pick today's Dormice copse and start with a clue that names two items outright, because the tick it gives you brings a row and a column of crosses with it. The Dormice archive is free and goes back to 10 September 2025.

ARLing also makes free daily logic puzzles.

Classic novels as PDF for reMarkable and Kindle Scribe: Monte Cristo and Ben-Hur with a notes band on every page

ARLing — Tue, 22 Sep 2026 08:30:00 +0000

Originally published at https://arling.sk/notes/classic-novels-pdf-remarkable-kindle-scribe-monte-cristo-ben-hur/

Classic novels as PDF for reMarkable and Kindle Scribe: Monte Cristo and Ben-Hur with a notes band on every page

The Count of Monte Cristo and Ben-Hur: A Tale of the Christ are in the public domain, and Project Gutenberg and Standard Ebooks offer both free of charge as EPUB. What an EPUB does not give you on an e-ink tablet is a fixed page with room under the text for your own handwriting. Classics for e-ink are those two novels typeset on a 157 x 210 mm page, with a cover on page 1, a band for notes with the pen that is also a PDF form field, a linked contents and a Contents link on every page, plus A4 and US Letter files for printing. The page is the 3:4 shape of a 10.3 inch e-ink display, so it fills the reMarkable 2, the reMarkable Paper Pro, the Kindle Scribe and Boox readers of that size without bars at the sides. This note goes through where the text comes from and what was not changed, how the page is set, what the finished files measure, and what we have not verified, because no file has been opened on a physical device yet.

The text, and what was not changed

Both texts come from Project Gutenberg as Plain Text UTF-8: ebook 2145, Ben-Hur by Lew Wallace, the original English text published by Harper and Brothers in New York in 1880, and ebook 1184, The Count of Monte Cristo by Alexandre Dumas with co-author Auguste Maquet, the anonymous English translation first published by Chapman and Hall in London in 1846, as reprinted in a later nineteenth-century edition with short editorial footnotes. Both records say "Public domain in the USA"; Dumas died in 1870, Maquet in 1888 and Wallace in 1905, and in the EU and Slovakia economic rights last 70 years after the author's death, or 70 years from publication for an anonymous work, so both are in the public domain here as well.

The sequence of words in the PDF equals the sequence of words in the body of the Gutenberg file, and two scripts check that: one at download and one in the finished PDF. What is omitted is the Gutenberg header and footer, the opening block with title, author and the Contents list, and the lines carrying illustration file names. Line breaks are reflowed, words marked with underscores in the transcription are set in italics and the common indentation of multi-line blocks is removed; the spelling and punctuation of the transcription are kept, and nothing is added, cut or modernised.

One thing about the source deserves saying plainly. The Project Gutenberg licence allows anyone to copy and build on a work that is unrestricted in the United States as long as all references to Project Gutenberg are removed; a work that keeps them may be sold only with a royalty of 20 percent of gross profits. That is why the PDF on sale contains no words Project Gutenberg, the edition page speaks of a public-domain digital transcription, and the source with ebook number, URL and sha256 is recorded in our README, in the manifest and in the listing outside the work.

How the page is set

The text is ARLing Serif at 13 pt on an 18 pt line, 22 lines to a page, with no hyphenation; measured on 17 September 2026, 13 pt gives an average of 64 characters per line. An 8 mm head carries the chapter label and title. At the foot is a 33 mm band for notes with the pen, with a dotted line, and under it an 8 mm footer with the Contents link, a 7.5 mm row for a finger, and the page number. The band is a form field, one on every text page, so you write in it with the pen on an e-ink tablet or type into it on a computer in Adobe Acrobat Reader, Preview or Firefox. The contents has a link to every chapter and part, 8.8 mm per entry, with a long title on two lines; a diagram is always whole on one page; nothing is below 10 pt. The fonts are embedded as Type0 from static instances, Source Serif 4 and Schibsted Grotesk under the SIL Open Font License 1.1, with 0 Type3 fonts.

The A4 and US Letter files carry the same 139 x 194 mm block centred on the sheet, so the pages, the page numbers and the links are the same in all three files. The links are ordinary links in HTML, and Chrome keeps them when it prints to PDF, as Link annotations with a destination inside the same file.

What the finished files measure

Ben-Hur is one file of 953 pages including the cover on page 1, 8 books and 81 chapters, with 1043 internal links and 91 link targets, 0 dead links, 0 pages with overflow, 2 diagrams whole on their page and 935 form fields, one on every text page. The text of all 81 chapters in the e-ink PDF was verified word by word against the data. The e-ink file is 5.35 MB, the A4 file 5.36 MB and the US Letter file 5.35 MB, decimal megabytes. The free sample is the first 3 chapters: 26 pages, 31 links, 21 fields, 0.42 MB.

The Count of Monte Cristo is issued in 5 volumes following the five parts of the source, each with a cover on page 1, its own title page, edition page and contents: 479, 523, 504, 414 and 367 pages, 2287 pages in all, 117 chapters, 2415 internal links and 133 link targets, 0 dead, and 2257 form fields in all, one on every text page. The e-ink volumes run from 2.21 MB (volume 5) to 3.11 MB (volume 2). For the shop there are three ZIP archives of 5 PDFs each, e-ink 13.56 MB, A4 13.57 MB and US Letter 13.55 MB, each under the 20 MB cap per file. The free sample is the first 3 chapters: 52 pages, 57 links, 47 fields, 0.55 MB. The 30 editorial footnotes of the source are the last section of volume 5.

Getting a file onto the reader is the same as with any other book: download it on a computer or phone and copy it over with the reMarkable desktop or mobile app, Send to Kindle for the Scribe, or a USB cable and the device folder for Boox. Nothing is installed and no account of ours is needed.

What we have not verified

No file has been opened on a physical reMarkable, Kindle Scribe, Boox or Supernote; the links, the notes band and the page counts are measured in the PDF only. The Etsy listings, 4.90 € per title in the ARLingPuzzles shop, went live on 17 September 2026: Ben-Hur is listing 4577382638 and The Count of Monte Cristo is listing 4577365779, each with five listing images. The Etsy limits we work to, 140 characters in the title, 13 tags of 20 characters, 5 files and 20 MB per file, and the acceptance of a ZIP as a digital file, are from memory, because help.etsy.com could not be read. The few Greek words in Monte Cristo are set in a fallback system font.

FAQ

Is the text complete and unchanged?

Yes: the sequence of words in the PDF equals the sequence of words in the body of the source file, checked by script at download and again in the finished PDF; only the Gutenberg header and footer, the opening block and the illustration file names are left out, and nothing is added, cut or modernised.

Why pay for a text that is free on Project Gutenberg?

The same texts are free as EPUB from Project Gutenberg and Standard Ebooks. What is paid for is the typesetting for an e-ink page, the notes band, the page numbers and the linked contents in a PDF, and the listing says so in its TEXT SOURCE block.

Why is Monte Cristo in five volumes?

Because the source itself is divided into five parts, VOLUME ONE to FIVE, and one file of all 2287 pages would be unwieldy; each volume has its own title page, edition page and contents, and the three ZIP archives keep each file under the 20 MB cap.

Where the books are

Classics for e-ink are sold as digital downloads in our Etsy shop for 4.90 € per title, once the listings are uploaded. Our other titles for the same page size are on the puzzle books page: ten printable puzzle books of 100 puzzles each, 4.90 € a book.

ARLing also publishes printable puzzle books.

Slitherlink SVG and JSON: inspect a sample before planning a layout

ARLing — Mon, 21 Sep 2026 08:30:00 +0000

Originally published at https://arling.sk/notes/slitherlink-svg-json-sample-for-layout/

Slitherlink SVG and JSON: inspect a sample before planning a layout

Slitherlink Pattern 01 is an evaluation preview of a fixed pack of 25 puzzles on 7 × 7 grids. Three puzzles from that pack form the sample. The full pack is available for €19 including VAT with a non-exclusive Commercial License; the free sample is for evaluation only.

Match the puzzle with its answer

Each sample has separate SVG files for the puzzle and its solution, plus PNG images, PDF sheets and a JSON record. Inspect the puzzle and solution files as separate parts of your intended layout. The three samples are part of the pack of 25, not an additional set.

Read the scope before publication

The duplicate check covers the current compared daily puzzle archive and the Otters book. It does not establish worldwide novelty or exclusivity. The free preview is for checking the format and layout. Commercial rights accompany a purchased pack, and other publishers may purchase the same non-exclusive set. The license permits unlimited printed copies in your own books, magazines, newspapers, newsletters and educational materials. It does not permit redistribution or resale of the source files or pack, marketplace uploads of the pack, or claiming authorship.

Inspect the sample

Open Puzzle Publisher to inspect the three samples in SVG, PDF, PNG and JSON. Purchase the full pack for €19 including VAT through Stripe and download the ZIP after payment verification. Downloading the free sample alone does not grant commercial publication rights.

You can check your own SEPA pain.001 file for free with the SEPA pain.001 Doctor.

CSV invoice batches: check the preview before downloading XML

ARLing — Sun, 20 Sep 2026 08:30:01 +0000

Originally published at https://arling.sk/notes/csv-invoice-batch-preview-before-download/

CSV invoice batches: check the preview before downloading XML

The ARLing batch generator turns CSV item rows into UBL XML. A batch can contain up to 100 invoices and 500 item rows in total. Preview and supported checks are free before purchase, so you can inspect the result before deciding whether to download the files.

Keep the invoice number consistent

Use the CSV column invoice_number to group items. Rows with the same value belong to the same invoice. Several item rows therefore do not necessarily mean several invoices; the limits apply to both invoice count and the total number of item rows.

Review before downloading

Run the batch check and inspect the invoice previews before continuing. Use the supported checks to review the input and resulting XML, rather than treating a generated file as proof that every requirement has been met. Downloading the prepared XML files together as a ZIP requires valid 30-day access.

Where the CSV is processed

The CSV content and generated XML are processed in your browser and are not sent to a server. This statement concerns the document content, not payment processing.

Try the batch preview

Open the CSV invoice batch page to inspect the supported input format, then use the e-invoice tool to preview and check a batch before downloading it.

ARLing also has a free e-invoicing tool.

XRechnung vs Peppol BIS Billing 3.0: A Guide for Foreign Suppliers

ARLing — Sat, 19 Sep 2026 08:29:50 +0000

Originally published at https://arling.sk/notes/xrechnung-vs-peppol-bis-what-a-foreign-supplier-must-know/

XRechnung vs Peppol BIS Billing 3.0: A Guide for Foreign Suppliers

If your company sits outside Germany and has just won a contract with a German business customer, two names will come up almost immediately: XRechnung and Peppol BIS Billing 3.0. Both describe a properly structured electronic invoice, and the difference between them decides whether the file you send actually gets accepted. Germany already requires every business to be able to receive a B2B electronic invoice, and on the receiving side an ordinary e-mail inbox is enough. The obligation to send one is being phased in on a schedule tied to company turnover, ending in a full cut-off after which every business must send electronic invoices. XRechnung is the German rulebook built directly on the same European core standard that Peppol BIS Billing 3.0 also sits on, which is exactly why the two get confused. This note walks through what XRechnung actually is, how it relates to Peppol BIS Billing 3.0, which invoice formats a German customer will accept, and which technical details commonly need checking before a foreign supplier's first invoice into Germany goes through.

What XRechnung Actually Is (and How Peppol BIS Billing 3.0 Fits Under It)

EN 16931 is the European standard behind every compliant electronic invoice: it fixes which data an invoice must carry and how the amounts on it must relate to one another. Its schematron splits into 58 base rules, numbered BR-01 to BR-65, plus a further 24 calculation and consistency rules, numbered BR-CO-01 to BR-CO-26. Peppol BIS Billing 3.0 is built directly on top of that same European standard, in the OASIS UBL 2.1 syntax, and adds 41 of its own rules on top of what EN 16931 already requires, in the release dated November 2025. XRechnung is Germany's own rulebook on the identical European standard, developed by KoSIT, and it already carries the Peppol BIS Billing 3.0 business rules inside it, which is exactly why a file built only to Peppol BIS Billing 3.0 does not automatically satisfy XRechnung, even though a file built correctly to XRechnung does satisfy Peppol BIS Billing 3.0.

The current release is XRechnung 3.0.2, and its base version, XRechnung 3.0, has applied since the start of February 2024.

Germany's Two Separate Deadlines: Receiving and Sending

Since the start of 2025, every business in Germany must be able to receive a B2B electronic invoice, and receiving one needs nothing more than an ordinary e-mail inbox on the customer's side; there is no special software requirement for a business that only receives invoices.

Sending is staged by turnover, and this is your German customer's own deadline, not a rule that binds a supplier outside Germany directly. A German business may still issue a plain PDF or paper invoice until the end of 2026, a company with a turnover up to 800 000 euro in the previous year keeps that option until the end of 2027, older EDI procedures outside EN 16931 are tolerated on the same 2027 date, and from the start of 2028 every business sends electronic invoices in B2B. Knowing these dates tells you exactly when a German buyer that still accepts a PDF today will start asking for XRechnung instead, so a request that seems sudden is really the customer catching up with a deadline it has known about for years.

Two Formats a German Customer Can Accept

XRechnung is not the only format that counts as a proper electronic invoice under German rules. ZUGFeRD is a hybrid file, an ordinary PDF with a structured XML file embedded inside it, and from version 2.0.1 it meets the legal definition of an electronic invoice, with one exception: its MINIMUM and BASIC-WL profiles leave out part of the EN 16931 data model and do not qualify.

A supplier whose own accounting software can only export a PDF should ask exactly which ZUGFeRD profile that software writes, because a file in the MINIMUM or BASIC-WL profile will not carry the full data set a German buyer's system is built to expect.

Identifiers and Rules That Trip Up a First Invoice Into Germany

Sending an invoice over the Peppol network to a German party means addressing it correctly. A German public authority is identified on the network by its Leitweg-ID, carried under scheme 0204, while a German VAT number, the USt-IdNr., is carried under scheme 9930; using the wrong one means the network cannot correctly match the invoice to the recipient.

The VAT category code on every invoice line has to be right as well. EN 16931 fixes a closed set of values: S for the standard rate, Z for a zero rate, E for exempt, AE for reverse charge, K for a supply inside the European Union, G for an export outside it, and further codes for special cases, and each of these carries its own group of calculation rules the invoice line has to satisfy.

For an invoice addressed to a German public buyer specifically, XRechnung's own rule BR-DE-15 requires the buyer reference field to be filled in; in practice this is exactly where the Leitweg-ID goes, and an invoice that leaves it empty is rejected before anyone even looks at the amounts.

FAQ

Do I have to use XRechnung, or is a Peppol BIS Billing 3.0 invoice enough?

XRechnung already carries the Peppol BIS Billing 3.0 business rules inside it, so a file built correctly to XRechnung also satisfies Peppol BIS Billing 3.0. The direction does not run the other way: XRechnung adds extra rules of its own, such as the mandatory buyer reference field, so a plain Peppol BIS Billing 3.0 file can still be missing something XRechnung demands.

Can I just keep sending a PDF invoice to my German customer?

For now, yes: Germany still allows a plain PDF or paper invoice until the end of 2026, with an extended option until the end of 2027 for a customer whose turnover in the previous year was up to 800 000 euro. The step worth taking now, rather than waiting for that date, is to ask whoever maintains your invoicing software whether it can already produce a file in the ZUGFeRD or XRechnung structure, since ZUGFeRD only counts as a proper electronic invoice from version 2.0.1 onward and an older version will not be enough once the deadline arrives.

What happens if I leave the buyer reference field blank on an invoice to a German public authority?

BR-DE-15 applies specifically to an invoice sent to a German public authority, where the buyer reference field is where the Leitweg-ID goes; it is not a general requirement stamped on every German invoice regardless of who the buyer is. The identifier in that field tells you which kind of buyer you are dealing with: a public authority is addressed under Peppol scheme 0204 for its Leitweg-ID, while an ordinary private company is addressed under scheme 9930 for its VAT number, so check which one applies to your customer before treating the field as optional.

Conclusion

None of this is homework you can skip because your own country runs a different scheme: the moment a German business customer asks for an electronic invoice, the file has to satisfy XRechnung or an accepted equivalent such as ZUGFeRD, not a rulebook borrowed from your home market. Getting the network identifiers, the VAT category code and fields such as the buyer reference right on the first attempt saves a rejected file and a second wait before the invoice gets paid. If you would rather check a finished invoice against these rules before it goes out, see ARLing's e-invoicing overview.

ARLing also has a free e-invoicing tool.

What Is EN 16931? The Core Invoice Standard Explained

ARLing — Fri, 18 Sep 2026 08:29:50 +0000

Originally published at https://arling.sk/notes/what-is-en-16931/

What Is EN 16931? The Core Invoice Standard Explained

EN 16931 is the European standard that defines what a compliant electronic invoice must actually contain: the semantic data model of the core invoice, meaning which data an invoice needs and how the pieces relate to each other. It is not a file format you attach to an e-mail; a document only counts as an electronic invoice when it is issued, sent and received in a structured format that a machine can process automatically, following EN 16931 in the UBL 2.1 or CII syntax. A PDF sent by e-mail or a scanned paper invoice does not meet that definition, no matter how correct the numbers on it look. Country-specific formats sit on top of this same core model instead of replacing it: Peppol BIS Billing 3.0 adds its own rules to EN 16931 rather than starting from scratch. None of this is theoretical for much longer. Slovakia introduces mandatory business-to-business electronic invoicing between domestic VAT payers from 2027, and Germany already requires companies to be able to receive electronic invoices. This note explains what the standard specifies, how national formats build on it, and why its VAT category codes matter in practice.

What EN 16931 actually specifies

EN 16931 works at the level of meaning, not markup. It sets out which data a compliant invoice must carry and how that data must relate to each other, so that a computer on the receiving end can process the invoice without a person retyping it. The schematron behind EN 16931 splits its checks into two kinds: core rules, numbered BR-01 through BR-65, of which 58 actually exist, and calculation and consistency rules, numbered BR-CO-01 through BR-CO-26, of which 24 exist. One of the calculation rules shows how concrete this gets: the schematron requires that the invoice total amount with VAT equal the total amount without VAT plus the total VAT amount, written formally as BT-112 equal to BT-109 plus BT-110.

That semantic model still needs an actual syntax to travel in. EN 16931 allows the data to be carried in either of two syntaxes, UBL 2.1 or CII, and a document following either one can satisfy the same underlying rules.

Why you rarely see "EN 16931" written on an invoice

EN 16931 is usually implemented through a profile built on top of it, because the standard leaves some choices open for individual sectors and countries to close. The common name for such a profile is a CIUS, and Peppol BIS Billing 3.0 is one of them: it keeps the EN 16931 syntax, UBL 2.1, and adds its own rules on top, coded PEPPOL-EN16931-R and PEPPOL-COMMON-R, 41 of them in the November 2025 release, some of which apply only to certain countries.

Slovakia does not have a separate national CIUS of its own; it uses Peppol BIS Billing 3.0 directly, extended only by national requirements that mainly set the mandatory network identifier. Germany went a different way and built its own CIUS, XRechnung, whose current version incorporates the Peppol BIS Billing 3.0 business rules while adding country-specific ones on top.

The VAT category code is part of the standard, not an afterthought

EN 16931 does not leave VAT treatment to guesswork either. A line-level VAT category code from the UNTDID 5305 list drives which values the standard recognises: S for the standard rate, Z for zero rated, E for exempt, AE for reverse charge, K for an intra community supply, G for export outside the European Union, O for not subject to VAT, and L and M for the Canary Islands and for Ceuta and Melilla.

Each of those codes drags its own rule group behind it. Categories S, Z, E, AE and G each carry ten rules of their own, O carries fourteen, and K carries twelve rules under the BR-IC group; picking the wrong category code on a line does not just misdescribe the tax treatment, it switches which set of rules the invoice gets checked against.

Where this already has a deadline attached

Slovakia's mandate is not a vague future plan. From 2027, domestic taxable business-to-business supplies between Slovak VAT payers must be invoiced electronically, under a new delivery service written into the VAT act. Invoices move over the Peppol network through certified delivery service providers, directly from issuer to recipient, with no central government system in between.

Germany moved first on the receiving side: since 2025, a business there must be able to receive an electronic invoice, and an ordinary e-mail inbox is enough to receive one.

FAQ

Is EN 16931 itself a file format I can export from my accounting software?

No. It is a semantic data model, and it needs a concrete syntax such as UBL 2.1 or CII, usually inside a country profile such as Peppol BIS Billing 3.0, before it becomes a file you actually send.

What should a business currently sending PDF invoices by e-mail do before the deadline?

Nothing has to change today, but the invoicing process itself has to move to the structured UBL 2.1 or CII syntax under EN 16931, sent over Peppol, before domestic taxable business-to-business supplies between Slovak VAT payers become mandatory in 2027. A business already trading with German counterparts should note that side moved first: since 2025 a business there must already be able to receive a structured invoice, even though an ordinary e-mail inbox is enough on the receiving side.

Why would an invoice get rejected specifically because of its VAT category code?

Because EN 16931 ties a different group of validation rules to each VAT category code from the UNTDID 5305 list. Take a reverse-charge line mistakenly marked S instead of AE: it stops being checked against the ten BR-AE rules built for a reverse-charge supply and starts being checked against the ten BR-S rules built for a standard-rated one instead, even though nothing about the actual supply changed.

Conclusion

Understanding EN 16931 matters most on the day the 2027 deadline in Slovakia stops being a compliance article and becomes a field in your own invoicing software that has to be filled in correctly. For a closer look at what a compliant electronic invoice needs to contain before that day arrives, see ARLing's e-invoicing overview.

ARLing also has a free e-invoicing tool.

SEPA File Rejected? What to Check in a Pain.001 File

ARLing — Thu, 17 Sep 2026 08:29:51 +0000

Originally published at https://arling.sk/notes/sepa-pain-001-file-rejected-what-to-check/

SEPA File Rejected? What to Check in a Pain.001 File

A rejected bulk payment file rarely comes with a clear reason, so finding the one broken element inside a pain.001 XML file by hand can take longer than fixing it once you know where to look. Most pain.001 validation errors come from a short, repeatable list: a transaction count or control sum that no longer matches the actual payments, an IBAN that fails its checksum, a BIC that does not exactly match the importing bank, or an execution date the bank will not accept. Since 15 November 2026 the SEPA schemes have added a new item to that list: when a payment carries a postal address, the address must be structured or hybrid, and a plain, unstructured address is no longer accepted. This note goes through what to check first when a bank rejects a bulk payment file, explains exactly what the new structured address rule requires, and shows how to run the whole check in your browser without sending the file to anyone.

What usually gets a bulk payment file rejected

Two numbers in the file header cause a large share of rejections: the transaction count has to equal the actual number of payment blocks in the file, and the control sum has to equal the exact total of all instructed amounts, to the cent. A mismatch usually shows up when someone adds or removes a payment without recalculating the header, and it is one of the most common reasons an import gets refused.

Both the debtor and creditor IBAN get checked for the right format, the length that country uses, and the checksum built into the IBAN itself; an IBAN written with spaces inside the file fails on that alone. The BIC of the debtor's own bank also has to match exactly the bank the file is imported into, not merely look like a valid BIC in general.

An execution date has to be a real calendar date that is not already in the past; Tatra banka and VÚB, for example, also refuse a date set too far ahead. The character set allowed in a SEPA file is limited to plain letters, digits and a short list of symbols; names and payment references that use accented letters need to be rewritten without them before export, since some banks cannot import the file at all otherwise.

The structured address rule that starts on 15 November 2026

From 15 November 2026 the SEPA schemes require that, when a payment does carry a postal address, that address is either structured or hybrid; a fully unstructured address, meaning free text only, is no longer accepted and the bank rejects the file. Version 1.0 of the same rulebook had listed 22 November 2026; version 1.1 corrected it to 15 November 2026, so a document that still says 22 November is quoting an outdated version.

The rule covers every SEPA scheme: a regular SEPA credit transfer, an instant SEPA credit transfer, and a SEPA direct debit, whether Core or B2B. More than one party inside a single file can carry an address at once, including the debtor, the creditor, the ultimate debtor and ultimate creditor, and the party that submits the file to the bank; one of them carrying the old address format is often enough for a bank to reject the whole batch, not only the one payment it belongs to, though whether a bank rejects one payment or the entire file is that bank's own choice.

What a structured or hybrid address actually needs

The minimum a structured or hybrid address needs is the town written in TwnNm and a two-letter country code in Ctry. That code has to follow the same two-letter list used worldwide, for example SK, CZ, DE or AT; the bank rejects a spelled-out country name just as it would any other invalid code. A hybrid address can keep at most two lines of free text in AdrLine alongside TwnNm and Ctry; three lines or more are refused even in a hybrid address.

None of this applies when a file carries no address at all: the address stays optional in a SEPA payment, and a file without any postal address passes after the deadline exactly the way it does today. The problem only sits in files that do carry an address, and carry it in the old, unstructured shape.

Checking your own file does not need special software: open it as plain text and search for the string PstlAdr. If that string is not there, the file has no address to fix. If it is there, it needs a town in TwnNm and a two-letter code in Ctry, and no more than two lines in AdrLine. The smallest edit that turns an old address into one that passes is adding TwnNm and Ctry to the existing PstlAdr block; a fully structured address goes further and splits the line into StrtNm, BldgNb, PstCd, TwnNm and Ctry, in the order the schema itself sets.

Which pain.001 version you use, and fixing the file in the browser

Both pain.001.001.03 and pain.001.001.09 can carry a structured address, so the November deadline is about the address, not about which version of the message you send; which version a bank accepts on import is that bank's own decision to make. The older, pain.001.001.03, address block covers StrtNm, BldgNb, PstCd, TwnNm and Ctry; the newer, pain.001.001.09, adds BldgNm, Flr, PstBx, Room, TwnLctnNm and DstrctNm, and narrows AdrLine itself to two lines.

The free SEPA pain.001 Doctor runs entirely in your browser, needs no account, and never sends the file anywhere, since there is no server behind the page at all. Pick your bank, and it walks through every element of the file, showing the exact path to the problem, the value it found, and a ready fix to paste back in. It is available in Slovak, German and English.

If the file keeps coming out of an older export in the unstructured shape, a separate browser tool builds a fresh pain.001 straight from a spreadsheet, with the address already split into street, building number, postal code, town and country, and it can write either version of the message.

FAQ

Does the 15 November 2026 rule affect a file that has no address at all?

No, the rule only reaches files that already carry a postal address. If you are not sure whether yours does, open it as plain text and search for PstlAdr; when that string is missing, there is nothing in the file to change.

Should I use pain.001.001.03 or pain.001.001.09?

Either version can carry the fields the new rule needs, so the more useful question is what your bank accepts on import, and that is each bank's own decision; ask your accounting software vendor which version it exports and from which release, and ask your bank which version it will keep accepting.

Can I check my file without installing anything or sending it to anyone?

Yes, everything happens locally in the browser tab, with no account and no upload needed. The page itself comes in Slovak, German and English; there is no separate Czech version, so a Czech-speaking user works from the Slovak one instead.

Fixing it now

Run your file through the free SEPA pain.001 Doctor first: it works in your browser, checks every element against the bank you pick, and shows the exact fix for anything from a bad checksum to an address still stuck in the old, unstructured shape.

If you handle payments for more than one client and need a written report you can pass on, the paid file check takes the file through an upload on the page and, within 24 hours, sends back a corrected pain.001 file together with a note on exactly which payments would fail after 15 November 2026 and the question to put to your accounting software vendor; it is a format check, not tax or legal advice, and ARLing is not a bank, so a clean result does not guarantee that the bank will accept the payment, since that decision stays with the bank.

You can check your own SEPA pain.001 file for free with the SEPA pain.001 Doctor.

Sudoku Corner, Centre and Colour Marks Explained

ARLing — Wed, 16 Sep 2026 08:29:49 +0000

Originally published at https://arling.sk/notes/sudoku-corner-centre-and-colour-marks-explained/

Sudoku Corner, Centre and Colour Marks Explained

Every sudoku player eventually needs somewhere to write a number down without committing to it, and that is where sudoku corner marks, centre marks and colour come in. Our sudoku controls give you four separate ways to mark a cell instead of one generic pencil mark, because a small digit in the corner of a cell means something different from the same digit in the centre. Corner marks place small candidate digits into the corners of the cell instead of scattering them across it, centre marks keep candidates together in the middle of the cell, and colour lets you shade a cell instead of writing anything into it at all. All four modes read the same keyboard, mouse and touch input, so once you know how selection works, switching between Normal, Corner, Centre and Colour is a single key press.

Selecting one cell or several at once

Before any mark goes into a cell, you have to select it, and our sudoku controls treat selection the same way whether you end up in Normal, Corner, Centre or Colour mode. A click or a tap picks one cell, dragging with the mouse or a finger across several cells picks all of them, and holding Ctrl while clicking adds a single cell to that selection or takes it back out.

Once cells are selected you can move the selection with the arrow keys, which wrap around the edge of the grid instead of stopping there, and WASD works as an alternative to the arrows. Escape clears the selection without touching anything you had already written. The given digits printed into the puzzle at the start can still be selected, for example to colour them or to place marks in the cells around them, but their own value cannot be overwritten.

The four entry modes: Normal, Corner, Centre and Colour

Normal mode writes the large digit that sits in the middle of an empty cell, the one you use when you are sure of the answer rather than noting a candidate. Corner mode writes small digits into the corners of the cell, Centre mode writes small digits into the middle of the cell, and Colour mode fills the whole cell with one of nine colours instead of a digit. You switch between the four with the keys Z, X, C and V, and the space bar cycles through all four in turn.

You do not always have to switch modes by hand. Holding Shift turns on Corner mode for as long as you keep it held, and holding Ctrl does the same for Centre mode, so you can drop into corner marks for one digit and return to whichever mode you were using the moment you let go.

Typing digits, clearing marks and undoing mistakes

Digits themselves go in with the number keys one to nine or with the numeric keypad; on a smaller grid you can only type up to the size of that grid. Backspace and Delete follow a fixed order in the selected cells: they clear a large digit first if one is there, then any corner or centre marks if there is no digit left, and only then the colour if nothing else remains.

Undo and Redo have no limit, and you can reach them with U, R, Ctrl+Z, Ctrl+Y or Ctrl+Shift+Z. Restart puts the given digits back the way they started and clears everything you added on top, but it is not a dead end: one Undo brings the whole grid back exactly as it was, and the clock keeps counting the whole time.

Default settings you can change before you start

Every sudoku on the site opens with the same starting settings, and all of them live in a menu you can reach before or during a game. Control method starts on Selection, meaning you pick the cell first and the digit second, Display timer starts switched on, and Highlight matching numbers starts switched off.

Default note style opens on Corner, so a fresh note lands as a corner mark until you choose otherwise, Auto remove restricted notes starts off, Auto pause is on so the clock stops itself while you are away, and Confirm before Restart is on so a stray key press cannot wipe a grid you were still solving.

Why Check never shows a red cell and you never truly have to guess

Nothing on the grid turns red while you are solving. The only way to learn about an error is to press Check, and it works in two steps: first a count of how many mistakes exist and roughly where they are, then, only if you ask again, the exact cells.

Hint works the same way in two steps of its own: first a sentence naming the technique to use and the general area, without giving away the value, then the highlight and the single move it unlocks. Both Check and Hint are free and unlimited while you play, they are only counted and shown together once you finish, and the timer on screen is a score you are trying to beat, never a limit that cuts your game short. That is possible because every puzzle you are given has exactly one solution, confirmed by the generator itself rather than by a person, and thrown away if a human solver could not finish it without a guess.

FAQ

What is the difference between corner marks and centre marks?

Corner marks sit in the corners of a cell and centre marks sit in the middle of it; they are two separate sets of small candidate digits, and Corner or Centre mode decides which set your next keystroke goes into.

Do the held Shift and Ctrl shortcuts replace the Z, X, C and V keys?

No, they add a shortcut on top of them. Z, X, C and V still switch you into Normal, Corner, Centre or Colour mode until you switch again by hand, while holding Shift or Ctrl only borrows Corner or Centre mode for as long as that key stays down.

Does pressing Escape erase my marks or my selected colour?

No. Escape only clears which cells are selected; it does not touch the digits, corner or centre marks, or the colour already sitting in those cells.

Try it today

Open today's puzzle and switch between Normal, Corner, Centre and Colour with a single key to see the difference on your own screen. Every puzzle behind that link still carries exactly one checked solution, and the same free, two step Check and Hint described above.

ARLing also makes free daily logic puzzles.

Peppol Invoice Validation Errors Explained

ARLing — Tue, 15 Sep 2026 08:29:50 +0000

Originally published at https://arling.sk/notes/peppol-invoice-validation-errors-explained/

Peppol Invoice Validation Errors Explained

When a business sends an electronic invoice over the Peppol network, the file has to pass a set of automated business rules before the recipient's system will accept it, and a peppol invoice rejected at this stage almost always comes back as a short code rather than a plain sentence explaining the problem. That short code is what shows up in the accounting software as a peppol validation error, and two rule books apply to the same file at once. The European standard EN 16931 defines the semantic data model of the core invoice and splits its checks into core rules labelled BR and the calculation and consistency rules labelled BR-CO. Peppol BIS Billing 3.0, the specification used directly in Slovakia and across the Peppol network, is built on top of EN 16931 and adds its own PEPPOL-EN16931-R and PEPPOL-COMMON-R rules for messages sent through the network itself. Every EN 16931 validation error therefore carries a BR code, and that code is the starting point for fixing the file before resending it.

Two layers of rules behind every BR code

EN 16931 alone lists 58 core BR rules plus 24 calculation and consistency rules under the BR-CO prefix. Peppol BIS Billing 3.0 does not replace these rules, it sits on top of them: the November 2025 release adds 41 further checks under the PEPPOL-EN16931-R and PEPPOL-COMMON-R codes, and part of that set applies only to specific countries rather than to every Peppol invoice.

Errors on the invoice number and the totals

The plainest example is BR-02: an invoice must carry an invoice number, referenced as BT-1 in the data model, and a file with that field empty is rejected outright rather than flagged as a warning.

Most totals errors are less about a missing field and more about arithmetic. BR-CO-10 requires the sum of the individual invoice line net amounts, BT-131 on each line, to equal the header line net total, BT-106. BR-CO-15 is reported even more often: the invoice total with VAT, BT-112, must equal the invoice total without VAT, BT-109, plus the total VAT amount, BT-110.

VAT category and currency code errors

Every invoice line and VAT breakdown carries a category code from the UNTDID 5305 list: S for standard rate, Z for zero rate, E for exempt, AE for reverse charge, K for an intra community supply, G for export outside the European Union, O for not subject to VAT, L for the Canary Islands and M for Ceuta and Melilla.

Each of these letters triggers its own group of checks: S, Z, E, AE and G each carry ten rules, O carries fourteen, and K carries twelve rules under the BR-IC prefix; the codes BR-K, BR-IG and BR-IP do not exist in the official rule set.

Currency causes a similar class of mistakes. BR-CL-04 requires the invoice currency code to follow the ISO 4217 alpha-3 list, so the field must read EUR rather than the word euro or a currency symbol, and a symbol in that field fails validation even when every amount on the invoice is correct.

Allowance and charge amounts

Discounts and surcharges on a line are checked for internal consistency rather than just for a value being present. PEPPOL-EN16931-R040 requires that, whenever both a base amount and a percentage are given for an allowance or a charge, the amount itself must equal the base amount multiplied by the percentage and divided by 100, so a discount figure that does not match the percentage typed next to it fails this rule even though both numbers look reasonable on their own.

FAQ

Why does my invoice fail even though every field looks filled in?

A filled field is not the same as a correct one: most rejections at this stage come from arithmetic checks across related fields rather than from a field being left empty, with BR-CO-15 the most frequently reported example.

Is EUR the only currency code Peppol invoices accept?

BR-CL-04 does not name a single currency: it requires whichever currency is used to be written as its ISO 4217 alpha-3 code, so EUR is correct for the euro while any other currency needs its own three-letter code from the same list.

Why does the validator report BR-IC instead of BR-K for an intra-EU supply?

Category K, the intra community supply code, is checked under the BR-IC group of twelve rules rather than under a code named after the letter itself; codes such as BR-K, BR-IG or BR-IP do not exist in the official rule set, so searching for them by that name will not turn up any documentation.

Conclusion

Reading the BR code correctly saves more time than rerunning the export and hoping the second attempt passes: a BR-CO code points to a calculation or consistency mismatch, most often a totals check, a PEPPOL-EN16931-R code points to a network-specific rule, and both name the exact business term you need to check in the accounting software before resending the file. Slovakia has no separate CIUS or schema of its own; it uses Peppol BIS Billing 3.0 directly, extended by the national PASR requirements that mainly set the mandatory network identifier, so the same BR and PEPPOL codes described here apply there too, alongside that extra identifier requirement; the eFaktúra overview covers the identifiers Slovak businesses need alongside these validation rules.

ARLing also has a free e-invoicing tool.

Peppol Invoice Rejected? Five Fields Worth Checking First

ARLing — Mon, 14 Sep 2026 08:29:50 +0000

Originally published at https://arling.sk/notes/peppol-invoice-five-fields-worth-checking-first/

Peppol Invoice Rejected? Five Fields Worth Checking First

A Peppol invoice rejected by the receiving side is almost never a random formatting glitch: it fails one specific, documented rule inside EN 16931, the European standard that defines the semantic data model of the core invoice, meaning which pieces of information an invoice must carry and how those values relate to each other. Peppol BIS Billing 3.0 then adds its own layer of checks on top of that standard, so a file that satisfies EN 16931 on its own can still be sent back once the Peppol rules run against it. For a small business that has never read a schematron error message before, the practical shortcut is not to study the whole specification line by line; it is to check five fields before the file leaves the accounting software: the invoice number, two totals that have to add up, the currency code, and one allowance calculation.

What EN 16931 and Peppol BIS Billing 3.0 Actually Check

EN 16931 is the European standard behind every Peppol invoice, and as already noted it sets out which pieces of information an invoice must contain and how those pieces relate to each other. Its own rules split into the core rules BR-01 to BR-65, of which 58 actually exist in the schematron, and the calculation and consistency rules BR-CO-01 to BR-CO-26, of which 24 exist.

Peppol BIS Billing 3.0 is a CIUS, a specification built on top of EN 16931 in the UBL 2.1 syntax, and it adds its own rules with the codes PEPPOL-EN16931-R and PEPPOL-COMMON-R on top of the standard's rules; in the release of November 2025 there are 41 of them, and some apply only to other countries, not Slovakia.

The Invoice Number and the Two Totals That Have to Add Up

The most basic rule in EN 16931 is also the simplest to check first. An invoice must carry an invoice number, formally BT-1, and the schematron text is direct: "[BR-02]-An Invoice shall have an Invoice number (BT-1)." A file where this field is left empty is rejected outright, regardless of whether the number is meant to be filled in later somewhere else in the process.

Another check worth looking at is a mismatch between the header and the line items. Rule BR-CO-10 requires that the sum of the invoice line net amounts, BT-131, equals the invoice line net amount total in the header, BT-106: "[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131)." This is what happens when a discount or a rounding step gets applied at the line level in one part of the software and at the header level in another.

The third failure sits one level up in the same chain of totals. Rule BR-CO-15 requires that the invoice total with VAT, BT-112, equals the invoice total without VAT, BT-109, plus the total VAT amount, BT-110: "[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)." It is reported as the most commonly seen totals error of all, and a single cent of rounding difference is enough to trigger it.

Currency Code and the Allowance That Must Match Its Own Math

A fourth field to check even though it looks trivial is the currency code itself. Rule BR-CL-04 states: "[BR-CL-04]-Invoice currency code MUST be coded using ISO code list 4217 alpha-3." The field has to hold a three letter code such as EUR, never the word euro written out and never a currency symbol.

The fifth field belongs to the Peppol layer rather than to EN 16931 itself. Rule PEPPOL-EN16931-R040 requires that when a discount or a surcharge on the invoice carries both a base amount and a percentage, the stated allowance or charge amount has to match that calculation exactly: "Allowance/charge amount must equal base amount * percentage/100 if base amount and percentage exists." A percentage that was rounded in one field of the accounting software while the amount was rounded separately is enough to break that match.

Why the VAT Category Code Multiplies the Checks on Your Invoice

Behind these five fields sits a further source of trouble that rarely shows up as a single rejection message on its own. The VAT category code on each invoice line, taken from the UNTDID 5305 code list, decides which entire family of rules the schematron applies to that line: S for the standard rate, Z for zero rated, E for exempt from VAT, AE for reverse charge, K for an intra community supply, G for an export outside the European Union, O for a supply not subject to VAT, plus L for the Canary Islands and M for Ceuta and Melilla.

Rule groups exist for the categories S, Z, E, AE and G with ten rules each, and O carries fourteen. For code K the group is called BR-IC and carries twelve rules of its own, not BR-K, which does not exist in the official schematron at all, so guessing the group name from the category letter is a mistake worth avoiding.

FAQ

My accounting software already produces a UBL file. Why would it still fail these checks?

Producing a syntactically correct UBL file only shows the software followed the file format, not that the numbers and codes inside it satisfy rules such as BR-02 or BR-CO-10, and Peppol BIS Billing 3.0 adds its own rules on top of EN 16931 that a plain UBL export can still miss.

Which of the five fields is worth checking first if there is only time for one?

The invoice number mapped to BT-1 is the simplest to check by hand and the most fundamental, since an invoice without one fails rule BR-02 outright before any of the totals are even compared.

Do these checks apply the same way to every VAT category on the invoice?

The five fields matter regardless of category, but the category code itself decides which extra group of rules also runs on that line, so a line coded as K, G or O is checked against a different set of conditions on top of the five fields above.

Conclusion

Checking these five fields by hand in a text editor works for a single invoice, but the totals inside BR-CO-10 and BR-CO-15 get tedious to verify once a business sends more than a handful of files, because every line and every rounding step feeds into the same header sum. The rules themselves come from the public EN 16931 schematron and the Peppol BIS Billing 3.0 schematron built on top of it, so the exact wording behind any error a piece of software reports can be looked up rather than guessed at. For more on the rules that Peppol invoice validation applies, see the ARLing e-invoicing pages.

ARLing also has a free e-invoicing tool.