beancount-importer-author

Subclass beangulp.importers.csvbase.Importer with declarative column descriptors for date, narration, and amount, and implement a narrow identify() that matches the header signature rather than just the .csv extension. Add the beangulp.testing.main self-test CLI block so the importer file can generate and verify golden files.

Reproduce the failure by running identify or extract on a new sample file, then diagnose the drift such as renamed headers or date format changes. Patch minimally, add the new sample to the test corpus with an eyeballed golden, and keep the old samples' goldens passing so historical re-imports still work.

csvbase.Importer provides declarative column mapping for CSV files with less code and fewer bugs, while a raw beangulp.Importer subclass is needed for formats csvbase cannot express, such as OFX files, multi-table exports, or unusual encodings.

No, beangulp is beancount-3-only. Users on beancount 2.x need the older beancount.ingest framework, which has a different API and should not be mixed with beangulp code.

This happens when a metadata() override returns a dict containing only custom keys like import-id, dropping the filename and lineno keys beangulp's sorting requires. Build on data.new_metadata(filepath, lineno) and add your keys to it instead of replacing it.

No, an importer should post only the source-account leg and never hardcode guessed counter-accounts. Categorization belongs to downstream hooks like smart_importer's PredictPostings applied at the multi-importer runner layer.