{
  "id": "p_1fhvD7GUYQ7Mn-6H",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_1fhvD7GUYQ7Mn-6H",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apievangelist"
  },
  "body": "A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: \"E-Invoicing: The Shape Of The Answer,\" Kin Lane, October 29, 2026, https://apievangelist.com/2026/10/29/e-invoicing-the-shape-of-the-answer/\n\nMarisol worked in accounts payable systems at a distributor, the kind of job where nobody thanks you until an invoice bounces. She read the post on a Thursday afternoon with a half-eaten sandwich beside her keyboard and a queue of rejected documents in another window.\n\nThe opening made her sit up. The business outcomes were stated plainly: turn a PDF that arrived as an email attachment into a structured e-invoice a buyer's system will accept. That was her whole week. Then came the line she read twice, \"There is no partial credit.\" She had spent years explaining this to colleagues who thought an invoice that was nearly right was nearly paid.\n\nShe liked the section on the shape being already written down. It listed Peppol BIS Billing 3.0, EN 16931, UBL, XRechnung, FatturaPA, and the code lists underneath them. She knew some of those names from error messages and had never thought of them as a gift. The post called the lists a set of enums, something a model could be held to. She tried to picture her own team's extraction tool held to the UNCL5305 subset and found she wanted that very much.\n\nThen she got uncomfortable. The author's argument leaned on rerunning a model on Tuesday and Friday and getting the same answer. The post said that if it didn't, \"you have an audit problem\". Marisol thought of the one time her team had run the same attachment through their tool twice and gotten two different tax categories. They had quietly picked the one that looked right and moved on. Nobody had written it down. She felt a small, specific shame, and then some irritation at the post for causing it.\n\nShe also disagreed with part of it. The post was hard on the certified operators, and its list of low scorers included companies she depended on. A low score in a catalog was not the same as a bad service on a Tuesday morning, and she said so aloud to nobody. But the post did not claim otherwise. It said it was reading public artifacts, and it admitted that some registers couldn't be read at all. She conceded that point grudgingly.\n\nWhat stayed with her was the section on where things fall short. The shape lives in XSD and Schematron, and the APIs wrap it as a base64 string field, \"useless to a constrained decoder\". She opened the vendor contract her company integrated against and searched for the invoice endpoint. There it was, a document field described as a string. No code list, no enum, nothing a model could be held to.\n\nShe did not have the authority to change a vendor, or the time to build a decoder. She didn't pretend otherwise. What she could do was small, so she did it before the sandwich was gone.\n\nShe exported the last month's rejected invoices into a spreadsheet and added a column for the tax category code on each. Next to it she pasted the published Peppol list of allowed values. Then she sorted by whichever codes did not appear on it. It was a dull, honest check, and it would take her about an hour.\n\nEleven rows were highlighted before she'd finished her coffee. She wrote the count at the top of the sheet and saved it where her manager would find it.",
  "title": "Fiction: A reader of \"E-Invoicing: The Shape Of The Answer\"",
  "topics": [
    "apis",
    "api-evangelist",
    "fiction"
  ],
  "published_at": "2026-10-29T13:08:51.107Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}