DEV Community: Gu

The function you wrote last month is a third-party API

Gu — Wed, 26 Aug 2026 03:36:35 +0000

There is a habit I have for other people's libraries that I do not have for my own code: before I call something, I read what it returns.

With my own functions I skip that, because I wrote them, so I know. Three times in three days that turned out to be false, and the third time I caught it before it cost anything only because I had started treating my own modules like somebody else's.

The version I had already been burned by twice

I maintain qbofile, a set of browser-based converters between the file formats accounting software uses. It is a small codebase: a parser per input format, a generator per output format, and pages that wire one to the other.

Wiring a new pair felt like plumbing, so I estimated it like plumbing. Two new pages, both reusing an existing parser and an existing generator: no new code. I said that out loud before opening either end.

The generator had no column for the thing the parser produced. The parser could read the category a user had assigned to each transaction; the CSV generator emitted six fixed columns and category was not one of them. Not a bug — it had simply never needed one, because the format it was originally written for does not carry categories.

That is a strange kind of wrong. Nothing was broken. The code did exactly what it always had. My model of it was built from the function name.

The same evening, in the same pair of modules, the second one:

L.push(`P${sanitizeText(tx.description)}`);

P is the payee field in that output format. M is the memo. Two fields, and upstream, description was defined as memo || payee. So for any transaction that had a memo, the memo took the payee slot and the actual payee was dropped. Silently — the file is valid, it imports fine, and the missing name never announces itself.

The two minutes that caught the third one

After the second one I wrote down a rule and did not really believe I needed it: before wiring two components together, open both ends and read what actually crosses.

Two days later I was writing a parser for another old format, and it needed to work out two things that the format does not state: whether dates are day-first or month-first, and whether a dot or a comma is the decimal mark. Both of those I had already solved elsewhere in the codebase. Reusing them was obviously right.

So I opened them. Not the call sites — the functions.

// what I was about to write
const fmt = detectDateFormat(dates);
if (fmt.ambiguous) warn(...);

const sep = detectDecimalSeparator(amounts);
parseAmountCents(raw, sep);

// what the functions actually do
export function detectDateFormat(values) {
  ...
  if (winners.length === 0) return null;      // ← returns null, does not throw
  return { format, ambiguous, rival, coverage };
}

export function detectDecimalSeparator(values) {
  ...
  return { sep: '.', ambiguous: true, evidence: null, samples };  // ← an object, not a character
}

Two crashes, neither of them written yet. fmt.ambiguous on a null, and an object handed to a function expecting '.' or ','.

Both were mine. Both were about two weeks old. I could have told you what they were for without hesitating, and I would have been right — and I still had the return shape wrong on both.

Why "I wrote it" is the reason, not the excuse

For a library I have never seen, the first thing I do is find out what comes back. For my own module I skip that step, and the thing I skip it in favour of is the function's name.

A name is a summary written before the function was finished. detectDecimalSeparator sounds like it returns a separator. It returns a separator plus the evidence for it plus whether the evidence was conclusive — because when I wrote it, the interesting part was that sometimes the file cannot tell you, and callers need to say so. That is a better function than the name suggests. The name just never got updated to admit it.

So the rule is not really "read your own code more carefully". It is narrower:

A function you have not opened in a few weeks is a dependency. Give it the courtesy you give a stranger's package: look at what it returns before you use it.

What types would and would not have caught

I write this project in plain JavaScript with JSDoc, so the obvious response is that a type checker catches all of this. It catches some of it.

detectDecimalSeparator returning an object where I expected a string — caught, instantly, that is exactly what type checking is for.
detectDateFormat returning null — caught, but only if I had annotated the return as nullable. The annotation is a claim I make by hand, and it is the same claim I got wrong in my head.
The generator with no category column — not caught by anything. Both sides were string[]. The type was right and the content was missing. No checker knows that a column named Category should exist because some other module can produce categories.

That last one is the one that cost the most time, and it is the one no tooling was going to hand me. Which is why the fix I ended up with is a reading habit and not a tool.

The whole check is a four-row table

Opening both ends does not mean rereading two files. In practice it is one grep per module — find the return statements — and one comparison of the field lists that cross the boundary.

For the parser and the generator, that comparison is a table you can write in a minute:

parser produces	generator writes
date	✅
amount	✅
payee	⚠️	overwritten by the memo
category	❌	no column

The two rows that are not a plain tick are the entire finding, and writing that table is the whole check.

Doing it took two minutes and turned up two crashes that did not exist yet. Skipping it, twice, shipped a converter that quietly dropped a field — and I found that one myself, by reading the code again, rather than from a bug report. That is the part worth sitting with: nothing about the output looked wrong, so there was no report coming.

If you have a QIF file whose dates come out in the wrong month, or a converter that disagrees with any of this, I would like to see it.

My tests could fail. They still could not tell me I was wrong.

Gu — Tue, 25 Aug 2026 01:52:58 +0000

A test proves your code does what you meant. It cannot prove that what you meant was correct.

I could have written that sentence a year ago. I still shipped on the wrong side of it this week.

Here is the assertion I was leaning on:

assert.equal(sumOf(splits), transaction.total)

A transaction split across several categories has to add up to the total. That is a real invariant, and the test catches plenty. What it cannot catch is the one thing I was actually unsure about, because both sides of that equation are produced by my code, using a sign convention I chose. Get the convention backwards and both sides flip together. The test stays green.

The two formats disagree about what a number means

I maintain qbofile, a browser based converter for the file formats small business accounting runs on. This particular conversion goes from IIF, which QuickBooks Desktop has used since the 1990s, into QIF, which Quicken and GnuCash read.

Spend $150 at one shop and split it between two categories. Here is IIF:

TRNS   ...   Amex Platinum      -150.00
SPL    ...   Office Supplies     100.00
SPL    ...   Meals                50.00

Double entry. The account side is negative, the category side is positive, and the whole block sums to zero.

QIF takes the same event from one point of view only, the account's:

T-150.00
SOffice Supplies
$-100.00
SMeals
$-50.00

The $ lines are negative here, and they sum to the T line rather than cancelling it. So the converter negates every split amount on the way across. One character:

L.push(`$${formatQifAmount(-s.amountCents)}`);

That character is a claim about how another company's file format works. I read the spec, I read other people's files, and I was fairly confident. Confident is not the same as measured.

The mutation test proved the wrong thing

Before trusting a test I like to break the code on purpose and check that the test notices. So I deleted the minus sign. Four tests went red, including the one above. Restore it, all green again.

That is a useful result. It rules out the test being vacuous, which is a real failure mode and more common than people admit.

But look at what it actually establishes. Flip a correct sign and the tests go red. Flip an incorrect sign and the tests also go red. The mutation test tells you the assertion is wired to the code. It is completely blind to whether the code is on the right side of the truth. I had proved my test could fail, and then quietly treated that as having proved my belief.

So I asked the software that has to read the output

The only authority on whether a QIF file is right is a program that imports QIF files. I built one file designed so that a sign error would be impossible to miss:

one credit card account, so the file also exercises the !Type:CCard header
two separate split transactions
one category that receives money from both of them — $100 from one, $120 from the other

That last point is the whole design. It gives me a number that only comes out right if the sign is right, and it comes from adding across two transactions rather than reading one back:

Category	Expected	Sign flipped would give
Office Supplies	220.00	-220.00
Meals	50.00	-50.00
Repairs	180.00	-180.00

Then I handed it to GnuCash. Import, no warnings, no "split does not balance". Office Supplies: 220.00. The account came in as a credit card rather than a bank account, so the type header was read too.

Fifteen minutes. The belief is now a measurement.

The bug I found on the way to the test

Deciding what was worth testing meant reading the whole chain again, and that is where the actual defect turned up. It had nothing to do with signs.

QIF has two separate fields: P for the payee, M for the memo. IIF carries both, in NAME and MEMO. The generator wrote one line:

L.push(`P${sanitizeText(tx.description)}`);

and upstream, description was defined as MEMO || NAME. So for any transaction that had a memo, the memo took the payee field and the actual payee was dropped on the floor.

before   PSUPPLIES RUN            <- memo posing as the payee, COSTCO gone
after    PCOSTCO / MSUPPLIES RUN

Nothing errors. The importing software has no way to know a field went missing, and neither does the person looking at their register afterwards. That is the failure mode this entire project exists to fight, and I had built one.

It was also the second time that day I had assumed a downstream generator could hold everything the upstream parser produces. The rule I wrote down: when you wire two components together, open the field lists at both ends and diff them. Do not just read the part in the middle that you are writing.

Which beliefs are worth fifteen minutes

You cannot run every assumption past real software; most of the time the unit test genuinely is the last word. What decided it here was a question I now ask explicitly:

Does this line rest on a belief about someone else's software?

Sign conventions in a foreign file format. Which header field another program actually reads. What an importer does with a value it does not recognise. Those are not properties of my code, so my code cannot testify about them, and a passing suite is the wrong kind of evidence entirely.

I had learned this once already and forgotten it. An earlier version of the same converter emitted an account type declaration, on the shared understanding that QuickBooks would create missing accounts with the type you declare. Every test passed. On a real copy of QuickBooks, every invented account came out as a bank account regardless of what the file said.

What makes this worth the interruption is the shape of the trade. Fifteen minutes buys an answer that no amount of additional test writing can produce, and the thing you are buying insurance against does not announce itself. A sign convention that is backwards does not crash anything. It produces a file that imports cleanly, into a register that looks plausible, for someone who has no way to check.

The IIF file I built for the GnuCash test, and the four things I checked after importing it, are in the repo notes. If you have a QIF importer that disagrees with any of this, I would like to hear about it.

A failed import that still created three records

Gu — Mon, 24 Aug 2026 00:55:09 +0000

Every importer has one moment where it tells you it is done.

Here is that moment, at the end of a file import into a twenty year old accounting product:

QuickBooks Information
Your data has been imported.

I have nine test files that produce that message. Two of them wrote no transactions at all, and one of those two still left three new records behind in the database on its way out.

That last part is the one that travels. If a format has no per record result channel, there is exactly one place left to tell the user what happened, and it fires whether or not anything worked. A partial write underneath it is invisible.

Nine files, each broken in one specific way

I maintain a browser based converter that turns bank CSV files into the formats accounting software will take. One of them is IIF, a tab separated format QuickBooks Desktop has used since the 1990s, with a reputation for failing quietly.

I had a specific worry. Our files reference accounts by name. If the name is not in the user's chart of accounts, what happens? Everyone writing about IIF says QuickBooks creates the account for you. Almost nobody says what kind of account it creates.

So I built five files, each broken in one way, and ran them against QuickBooks Mac Plus 2024 in a throwaway company file. Four more came later, for a reason I will get to.

Two of the five said imported and posted nothing

The file	What QuickBooks showed	What actually happened
Valid, account exists	Your data has been imported	Posted correctly
Unknown name in the NAME field	Your data has been imported	Posted. Name created as an "Other Name"
Receivable with no customer	Warning, then Your data has been imported	Nothing posted
Amount written `-1,234.56`	Your data has been imported	Posted correctly as -1234.56
Two sides that do not balance	Warning, then Your data has been imported	Nothing posted

Here is the warning from the unbalanced file, the one thing that distinguished a failed run from a good one:

Transaction is not in balance. Make sure the amounts in the detail
area on the form for this transaction equal the amount at the top
of the form.

That reads like instructions for a form you are looking at. There is no form. There is one button, it says OK, and it takes you to the success message.

So the warning was the result, and clicking OK destroyed the only copy of it.

I went looking for the copy that should have survived. QuickBooks for Windows 2019 and later is widely described as writing a line by line import report with numbered error codes, and people quote things like [3040] on Intuit's forums. None of my imports produced one, and the app's own log held internal identifiers and nothing else. On this build the dialog you clicked past is the entire record.

Every account it invented was a bank account

The company file started with exactly one account in it. Everything else the five files referenced was missing on purpose. QuickBooks created all of them without asking, and gave all of them the same type:

Name in the file	Type it should be	Type QuickBooks made	Created during
`Uncategorized Expense`	Expense	Bank	a run that posted
`Accounts Receivable`	Accounts Receivable	Bank	a run that posted nothing
`Uncategorized Income`	Income	Bank	a run that posted nothing

It does not infer the type from the name, not even for names QuickBooks itself uses. It does not infer it from how the account is used in the file. It creates a bank account and moves on.

A wrong account name announces itself, because the account appears in the wrong place and somebody goes and fixes it. A wrong account type does not. Expenses sit in something that looks like a bank account, the profit and loss report is missing them, and every total involved is wrong until someone notices.

The failure was only half a failure

Look at the right hand column again. Two of those three accounts were created by the receivable file, and the receivable file is one of the two that wrote no transactions.

So that run rejected the transaction and kept the side effects. Nothing was posted, two new accounts were left behind in the chart of accounts, both of them the wrong type, and the last thing on screen said the data had been imported.

That is the case worth designing for if you consume other people's files. "It failed" is not the same statement as "nothing happened", and a user who is only told the first one will assume the second.

We had been telling people the opposite

This is the part I would rather not write. Our own converter pages said that Uncategorized Expense and Uncategorized Income are accounts QuickBooks ships with, so they would always be there and the category side of every entry was safe.

I did not measure that before publishing it. I read it, it matched what everyone else says, and it went on the page as a reassurance. The blank company file had neither account. The line had been sitting there telling people not to worry about the exact thing that was going wrong.

Both pages now say what the test found instead.

The fix, and the test that had to come first

IIF has a section that carries account types:

!ACCNT  NAME    ACCNTTYPE
ACCNT   Amex Platinum   CCARD
ACCNT   Uncategorized Expense   EXP
ACCNT   Uncategorized Income    INC

We had deliberately not written that section, on the reasoning that creating accounts in somebody's books is a bigger thing to get wrong than a bad import you can restore from backup.

That reasoning was wrong, and measuring is what showed it. We were never choosing between creating accounts and not creating them. QuickBooks creates the missing ones either way. We were only choosing whether they came out with the right type.

That still left the question of whether the section is safe, which needed a second round of files. The one that mattered declares an account that already exists as the wrong type. If !ACCNT can retype an account somebody is already using, this fix is worse than the bug: instead of a stray account in a new file, you have a corrupted chart of accounts in a real one.

It cannot. The account was still a bank account afterwards. The section fills gaps and leaves everything else alone. That is the result that made the change shippable, and out of nine files it is the only one whose answer could have stopped it.

The two rules I came out with

Put the outcome where dismissing it does not destroy it. A modal warning is gone the moment someone clicks OK, and on the build I tested nothing else recorded it. The user is then holding a screen that says the import succeeded and no way to find out otherwise except by counting rows.

Before changing how a tool writes to somebody else's data, write the test whose result would stop you, and run that one first. Eight of my nine files told me things worth knowing. Only one of them could have cancelled the change, and if I had run it last I would have built the whole thing before finding out.

The converter is at qbofile.com. It runs in the browser, nothing is uploaded, and every file it writes now declares its account types.

Is 1.234 one, or one thousand? Getting CSV decimal separators right

Gu — Thu, 20 Aug 2026 01:02:41 +0000

Here is a number from a bank statement:

1.234

If the bank is American, that is one point two three four. If the bank is German, that is one thousand two hundred and thirty four. Same characters, 1000x apart.

You cannot tell which one it is by looking at it. That is the whole problem.

We had already solved this. For dates.

I build a browser-based converter that turns bank CSV files into formats accounting software will accept. Three weeks ago I wrote this comment at the top of the date parser:

The most dangerous thing here: MM/DD/YYYY and DD/MM/YYYY look identical. 03/04/2024 is either March 4th or April 3rd, and a single value can never tell you which. The fix is to judge the whole column at once. Raising a warning matters, because a whole column of wrong dates shifts the books by a month, and it is the kind of error that looks fine.

Every word of that applies to amounts. I did not notice.

The amount parser was guessing one value at a time:

// only comma present: is it a decimal point or a thousands separator?
// guess from whether exactly 3 digits follow it
const tail = s.slice(lastComma + 1);
const isGrouping = tail.length === 3 && /^\d{3}$/.test(tail);

That heuristic is fine on 1,234 and fine on 12,50. It is wrong on 1.234, and it is wrong silently.

What it costs

Three lines from a German statement, before the fix:

in the file	we read it as	the bank meant
`-1.234`	-1.23	-1234.00
`2.500`	2.50	2500.00
`-12,50`	-12.50	-12.50

Every amount in the column comes out 1000x too small. Nothing throws. The import succeeds. The register looks normal. You find out at reconciliation, if you find out at all.

Rent showing up as 1.23 is not a crash. It is a number that sits there looking like a number.

The fix is the same one, applied to the other column

Look at the whole column and find a value that gives the answer away. In order of strength:

Both separators in one value. 1,234.56 or 1.234,56. Whichever comes last is the decimal point. This settles it immediately.
A separator with something other than 3 digits after it. 12,5 cannot be a thousands separator. Neither can 1,2345.
The same separator twice in one value. 1.234.567 means the dot is grouping.
None of the above. Every value in the column looks like 1.234. Now you genuinely cannot tell.

Rule 4 is the one that matters. Most parsers pick a default here and say nothing. We pick US convention and raise a warning:

Amounts like "1.234" could mean 1.234 or 1,234. Every value in this file has
exactly three digits after the separator, so the file alone can't tell us.
We read "." as the decimal point (US convention). If this statement is
European, every amount is 1000x too small.

One qualifying value rescues the entire column. In the German sample above, -12,50 does it: two digits after the comma, so the comma is not grouping, so the column is European, so -1.234 is 1234.00.

A detail I only found by writing the test wrong

My first test file used commas as the CSV delimiter:

Date,Description,Amount
06/04/2024,KAFFEE,-12,50

That row has four fields, not three. Which is exactly why European CSV files use semicolons. The comma was already taken.

The part I actually want to remember

The method was already in the codebase. I wrote it down myself, in a comment, at the top of a file I open regularly. Then I wrote a second parser with the same class of ambiguity and guessed value by value for three weeks.

Writing something down is not the same as remembering it. When the same shape of problem shows up a second time, the useful move is to go look at how you solved it the first time, and I did not.

The converter is at qbofile.com if you want to see the behaviour. It runs entirely in the browser, so nothing gets uploaded.

IIF, the QuickBooks import format with no way to report an error

Gu — Tue, 18 Aug 2026 01:57:47 +0000

I maintain a browser-based converter that turns bank CSV exports into the file formats QuickBooks accepts. One of those formats is IIF, which is what QuickBooks Desktop uses for bulk imports, and it has a property I hadn't thought carefully about until last week: it has no way to report an error.

An IIF file is tab-separated text. Here is one my converter produced for a credit card statement, which is the file the rest of this post is about:

!TRNS   TRNSID  TRNSTYPE    DATE    ACCNT   NAME    AMOUNT  DOCNUM  MEMO
!SPL    SPLID   TRNSTYPE    DATE    ACCNT   NAME    AMOUNT  DOCNUM  MEMO
!ENDTRNS
TRNS        CREDIT CARD CHARGE  01/05/2024  Visa Card       -12.40      COFFEE SHOP 4471
SPL     CREDIT CARD CHARGE  01/05/2024  Uncategorized Expense       12.40       COFFEE SHOP 4471
ENDTRNS

Rows beginning ! declare columns; the rest are data. Each transaction names the account it belongs to in ACCNT — by name, as a string, matched against whatever is in the user's chart of accounts. There is no account number and no identifier, and no column anywhere says what kind of account it is. Just a name.

Every write-up I could find mentions what happens when that name doesn't match: QuickBooks creates a new account rather than complaining. I had that sentence on my own site, sourced from several places that all said the same thing, and I'd never seen it happen. So I finally set up a scratch company file and watched.

The test

Two imports through File › Utilities › Import › IIF Files, both from a credit card statement, both containing the same transactions with CREDIT CARD CHARGE and CREDIT CARD CREDIT transaction types. The only difference was the account name.

The first import named an account that did not exist. QuickBooks reported success. It did not prompt, it did not warn, and it created the account. All of that matched what I expected.

What I hadn't expected was the account it created. It was a Bank account — for a credit card statement. And that changed the transactions as well, because a Bank account cannot hold a credit card charge. The register showed CHK and DEP where the file had said CREDIT CARD CHARGE and CREDIT CARD CREDIT.

The second import pointed the same file at a Credit Card account that already existed, and everything landed correctly:

In the file	Real Credit Card account	Auto-created account
`CREDIT CARD CHARGE`	`CC`	`CHK`
`CREDIT CARD CREDIT`	`CC CRED`	`DEP`

Signs behaved correctly in the second case too — a charge increased the balance owed, a payment reduced it — which settled a separate question I'd had, since published sources disagree about whether the right transaction types are CREDIT CARD CHARGE/CREDIT CARD CREDIT or CREDIT CARD/CCARD REFUND. The first pair is correct.

Why it behaves this way

A typo in an account name doesn't produce a duplicate account you clean up later. It produces an account of the wrong kind, holding transactions of the wrong type, and the import that did it reported success. In bookkeeping terms a liability has quietly become an asset. Nothing in the process ever says so; you find out at reconciliation.

That outcome isn't a bug so much as the only thing the format leaves available. IIF was designed for bulk loading, so the importer is built to complete rather than to validate, and it runs without a user sitting in front of it. When it meets a name it doesn't know it has two options: refuse the whole file, or guess. It guesses, and it guesses Bank.

What makes it worth a second look is that the guess ignores evidence the file does supply. Look at the row above: TRNSTYPE and ACCNT are on the same line, so the line that names the unknown account also says CREDIT CARD CHARGE. The importer creates a Bank account anyway, and then rewrites the transaction into something a Bank account can hold.

Every part of that is locally reasonable. The result is still a silent corruption of someone's books.

It's a useful contrast with the other format I generate. A QBO file lands in the bank feed's review queue, where each transaction is matched and approved before anything is recorded, and the account is identified by a number the bank issued rather than a name a human typed. The failure mode there is "nothing happens and you don't know why," which is annoying but recoverable. The IIF failure mode is "everything happens and looks fine."

What I changed

The copy on my converter used to say what everyone else says: make sure the account name matches your chart of accounts exactly, because otherwise QuickBooks will create a new account. That's true, and it's incomplete in a way that matters, because it implies the worst case is an extra account. The requirement is actually stronger — the account has to already exist, with the correct type, because nothing in the file says what kind of account it is, the importer won't infer it from the transaction type, and it will not ask.

I also can't tell you whether changing the invented account's type from Bank to Credit Card afterwards produces correct results, because I didn't test it and I'm not going to assume. Restoring the backup is the fix I can vouch for, which is a good argument for taking one, since an IIF import writes straight into the company file with no undo.

One more gap worth stating: I ran this on QuickBooks Desktop for Mac. The IIF importer is the same feature on Windows and I have no particular reason to expect it to differ, but I haven't checked, so I'd be glad to hear from anyone who has.

The full write-up, with both imports side by side, is at qbofile.com if it's useful to you.

Reading .xlsx in the browser without a spreadsheet library

Gu — Mon, 17 Aug 2026 06:14:06 +0000

I run a small site that converts bank CSV exports into the file format QuickBooks Desktop accepts. The whole thing runs client-side, and the privacy claim it makes is unusually literal: every page ships a Content Security Policy with connect-src 'none', so the browser refuses to let the page make any network request at all. Open the Network tab while you convert a file and it stays empty. That's the feature, not a nice-to-have on top of it.

When I added Excel support last week, the obvious choice was SheetJS. I decided against it, and the reason wasn't bundle size. The claim I want to be able to make is "your file never leaves the browser, and here is the policy that enforces it." Pulling in a large third-party parser turns that into "…and also trust this dependency," which is a materially weaker claim for a tool that handles people's bank statements. So I wanted to find out how much of the format I actually needed.

Less than I expected. An .xlsx file is a ZIP archive containing XML: xl/workbook.xml lists the sheets, xl/worksheets/sheet1.xml holds the cells, xl/sharedStrings.xml is a deduplicated string pool that cells reference by index, and xl/styles.xml carries the number formats. Reading that needs three capabilities, and the browser already provides two of them. Unzipping means walking the ZIP central directory, which is about forty lines. Decompression is DecompressionStream('deflate-raw'), which is native. For the XML I hand-rolled a tag scanner rather than reaching for DOMParser, because my tests run in Node where DOMParser doesn't exist, and I would rather have one code path than two.

Dates

The part that took the most care was dates, because Excel doesn't store them as dates. A cell holding 5 January 2024 contains the number 45296, and whether that number should be displayed as a date depends on the cell's number format — which lives in a different file inside the archive. So the parser has to read styles.xml, work out which style indexes correspond to date formats, and check every numeric cell against that list.

Both failure modes are bad, and neither of them raises an error. Miss a date format and the user's date column arrives as a column of five-digit numbers, which at least looks wrong. Treat a currency format as a date and an amount that happens to be 45296 silently becomes a day in January 2024, which doesn't.

Then there's the epoch, which is 1899-12-30 rather than 1900-01-01. Excel believes 1900 was a leap year and reserves serial 60 for a 29 February that never existed, so starting a day and a half earlier makes everything from March 1900 onward line up. Bank statements don't reach back that far, so the gap never surfaces. Older Mac files are a separate case: they use a 1904 epoch, flagged by date1904="1" on workbookPr, and missing that attribute puts every date in the file off by four years and a day.

The bug that cost me an afternoon

I wrote 26 tests against workbooks the test suite generates itself, covering the date handling, sparse cells, shared strings and sheet selection. All of them passed. Then I opened the real page in a browser, dropped a file on it, and got back a single line:

Failed to fetch

Nothing in the parser fetches anything, and the page it runs on is specifically configured so that fetching is impossible. The line responsible was this one:

const ds = new DecompressionStream('deflate-raw');
const writer = ds.writable.getWriter();
writer.write(bytes);
writer.close();
const out = await new Response(ds.readable).arrayBuffer();

Wrapping a stream in a Response and calling arrayBuffer() is the tidiest way to collect its output, and it's what most examples show. Chrome treats it as a fetch, connect-src 'none' blocks it, and the error it returns reads like a network failure in code that has no network. Because Node doesn't enforce CSP, the test suite could never have caught this, which is the part I'd want to remember: a green suite told me nothing about whether the code worked on the page it was written for.

Draining the stream by hand avoids the problem entirely:

const reader = ds.readable.getReader();
const chunks = [];
for (;;) {
  const { done, value } = await reader.read();
  if (done) break;
  chunks.push(value);
}

There is a smaller companion problem worth knowing about. When the compressed data is corrupt, the writer side of the stream rejects as well as the reader side, so unless you attach a .catch() to both writer.write() and writer.close() you get an Uncaught (in promise) in the console sitting next to the error you are already handling correctly. A handled failure ends up looking unhandled.

What I left out

I don't read .xls. It's an OLE compound document rather than a ZIP — a genuinely different format that happens to have a similar name — so the converter detects it and asks the user to save as .xlsx first. Zip64 archives bail out with a message rather than being supported, on the grounds that I have yet to meet a four-gigabyte bank statement.

Multiple sheets is the decision I'm least happy with. A workbook often has a cover page, a summary tab and the actual transactions somewhere in the middle, and there's no reliable signal for which one the user meant. I take the first sheet with more than one row of data and name it in the results panel so the choice is at least visible, but that's a compromise rather than a solution; every alternative I considered came down to asking the user a question they don't want to be asked.

One thing I haven't been able to confirm is whether new Response(stream) counts against connect-src in Firefox and Safari the way it does in Chrome. If anyone knows, I'd be glad to hear it — the workaround is harmless either way, but the diagnosis took long enough that I'd rather it were written down somewhere.

The parser is at /src/xlsx/parse.js on qbofile.com, unminified, if you'd like to look at it.

Notes from getting QuickBooks to accept a generated .qbo file

Gu — Fri, 14 Aug 2026 03:24:14 +0000

I'm building a small tool that converts bank CSV files into .qbo files for QuickBooks (qbofile.com). When a generated file is wrong, QuickBooks rejects it with vague errors and the OFX spec doesn't tell you what QuickBooks actually checks. So I ran some experiments. Notes below, in case someone else hits the same wall.

The file is not XML

.qbo is Intuit's version of OFX 1.0.2, which is SGML. Leaf tags have no closing tag:

<TRNAMT>-42.50
<FITID>8f3a2b...

Only aggregate tags close. The file also needs a 9-line key:value header, then one blank line, then the body. Line endings are CRLF. My first bug was closing every tag like XML.

"Missing bid data" means one tag: INTU.BID

QuickBooks checks <INTU.BID> against an internal list of banks that pay Intuit for Web Connect. I tested three variants on QuickBooks Desktop for Mac 2024:

Variant	Result
No `<FI>` block, no `<INTU.BID>`	Rejected: "Missing bid data"
Only `<INTU.BID>`	Accepted
`<FI>` block + `<INTU.BID>`	Accepted

So the whole <FI> block (bank name, org id) can be dropped, but INTU.BID cannot. I have only tested the Mac version. If you know whether Windows versions behave the same, I'd like to hear.

FITID decides duplicates

QuickBooks dedupes on FITID, not on date + amount. If a converter generates random FITIDs, re-importing an overlapping date range creates duplicate transactions. I hash account + date + amount + description, so the same transaction always gets the same FITID. Credit card statement cycles never match calendar months, so overlapping imports happen more often than I expected.

QuickBooks cannot export .qbo

This one surprised me. No version of QuickBooks can produce a .qbo file. The format only goes one direction, from bank to QuickBooks. Every .qbo file in the world came from a bank's download button or from a converter.

That's what I have so far. The tool is free for single files and runs fully in the browser, nothing gets uploaded. I have only tested against QuickBooks Desktop — if you use QuickBooks Online, I'm interested in what its importer accepts.