DEV Community: Feroz Sheikh

Parsing bank-statement PDFs in the browser: text layer, tables, and a balance check

Feroz Sheikh — Sun, 04 Oct 2026 05:48:13 +0000

Generic "PDF to Excel" converters are great until you feed them a bank statement. Columns drift, page headers repeat mid-table, wrapped descriptions become extra rows, and the closing balance no longer matches the opening balance plus the sum of amounts. That is not a minor formatting bug — it is a wrong ledger.

I spent a while on this while building a free, browser-only converter for text-layer statements. Here is the practical checklist I wish I had on day one.

1. Confirm there is a real text layer

Open the PDF and try to select a single transaction line. If you cannot select text, or you get mojibake, you have a scan (or broken font encoding). Ordinary converters will invent numbers. You need OCR in the statement language first, and you should budget time to fix rows by hand.

If selection works, you have a text PDF. Prefer a table-aware extractor over a full-page "PDF to Word" pass:

Excel (Microsoft 365 on Windows): Data → Get Data → From File → From PDF, then pick the table on each page
Tabula (open source): draw a box around the transaction table and export CSV

2. Prefer the bank export when it exists

Most online banking apps can export CSV or Excel for a date range. That path beats every PDF pipeline. Use the PDF route only when the bank will not give you a spreadsheet (or you only have the PDF the branch emailed).

3. Reconcile row by row, not "looks about right"

After extraction, start from the opening balance and walk each row:

previous_balance ± amount  ==  new_balance

Any failure is a split cell, a merged cell, a repeated page header, or a description that wrapped onto a second line. Those four failure modes cover almost every "converted mess" I have seen.

A small implementation tip in JavaScript: keep amounts as integers of the minor unit (pence/cents) while you walk the ledger, and only format for display at the end. Floating-point drift will otherwise create false mismatches on long statements.

4. Keep the file on the device

Bank statements are high-sensitivity documents. Uploading them to a random converter is a privacy decision, not just a convenience one. A client-side parser (pdf.js + your own column heuristics) never sends the bytes to a server. Trade-off: large scanned PDFs OCR slowly in the browser, and you will not magically fix a true scan without an OCR engine that supports the language.

Disclosure

I built a free browser converter that runs this balance check locally on text PDFs (not scans): opentoolsuite.com/guides/convert-bank-statement-pdf-to-excel. Use it, or rebuild the same pattern with Tabula + a spreadsheet — the reconciliation step is the part that actually matters.

Versioned construction formulas: how Construclytic shows the math behind every calculator

Feroz Sheikh — Thu, 01 Oct 2026 06:08:37 +0000

Most construction calculators hide the arithmetic. You type room size, you get a carton count, and you have no idea whether waste was 5% or 15%, whether the coverage came from the carton label, or whether the code will still produce the same number in eighteen months.

I built Construclytic to do the opposite: every published calculator carries a formula ID, a version, a worked example, and a visible calculation trail. The arithmetic is deterministic TypeScript — not LLM-generated totals. Here is how that looks in practice, using the laminate flooring calculator as the example.

Formula IDs are product SKUs for math

The laminate calculator publishes FLOOR-LAMINATE-001 (currently v1.0.0). That ID shows up on the result card, in the estimate line, and in the formula registry. If a correction ships, the version bumps and the changelog says so.

The core expression is intentionally boring:

cartons = ceil( L × W × (1 + waste) ÷ carton_coverage )

L × W is the measured floor area
waste is an explicit input (default for planning; higher for diagonal / complex layouts)
carton_coverage is the square footage printed on the carton you chose
Rounding to whole cartons happens once, at the end

That is the same method a careful estimator uses on paper. Making it a named, versioned formula means a saved quote from October still explains itself next spring.

Waste is an input, not a hidden multiplier

Black-box tools often bake in “about 10%” without saying so. FLOOR-LAMINATE-001 keeps waste as a field:

Straight-lay rooms: often ~8–10%
Diagonal or busy layouts: 12–15%+
Click-lock and glue-down do not share a silent default — the coverage and allowance stay on the form

For a worked Quora-sized room (12 × 5 ft, 27 ft² cartons, 10% waste):

area        = 60 ft²
with waste  = 66 ft²
cartons     = ceil(66 / 27) = 3

Even with 0% waste you still need 3 cartons (60 ÷ 27 = 2.22). The third carton is spare stock for future repairs — and matching lot numbers later is harder than people expect.

You can try the same inputs live: construclytic.com/calculators/flooring/laminate.

What “tested” means (and what it does not)

Each published calculator has automated checks: Imperial/Metric round-trips, finite results on equivalent projects, and known-answer cases for selected formulas. The how-we-calculate page and public formula registry record the tested version and date.

What we do not claim: independent third-party engineering review, mix design, code compliance, or a supplier quote. Construclytic is a planning workspace. Field checks stay with you.

Why transparency matters for estimators

Auditability. A client or GC can see why you ordered 14 cartons, not 12.
Reproducibility. Same inputs + same formula version → same purchase quantity months later.
Teaching. Juniors learn the takeoff chain instead of trusting a magic number.
Diffability. When waste defaults or coverage rules change, the version bump is the signal.

If you are building calculators yourself, the pattern transfers outside construction: name the formula, version it, show the trail, keep policy knobs (waste, packaging steps, tax) as inputs, and never let an LLM invent the numeric result.

Disclosure

I built Construclytic. The laminate calculator above is free, needs no account, and shows FLOOR-LAMINATE-001 on the result. Methodology: construclytic.com/how-we-calculate.

UK flight delay compensation (UK261) explained — how much you can claim

Feroz Sheikh — Wed, 30 Sep 2026 06:18:35 +0000

If your flight arrived hours late, you may be owed a fixed cash amount from the airline, on top of meals and a hotel. In the UK these rules are known as UK261, the version of EU Regulation 261/2004 that the UK kept after Brexit.

It helps to separate three questions: Is my flight covered? How late did I arrive? Why was it late? This guide answers each one using the Civil Aviation Authority's (CAA) own figures.

1. Is your flight covered?

According to the CAA, UK261 covers a flight if it is:

departing from a UK airport, on any airline, or
arriving at a UK airport on a UK or EU airline, or
arriving at an EU airport on a UK airline.

The reverse catches people out: a flight into the UK on a non-UK, non-EU airline (say, a US carrier from New York) is generally not covered, while the same airline's flight out of the UK is.

What matters is the airline that actually operated the flight, not the one that sold you the ticket or appears in a codeshare.

2. How much: the four CAA amounts

Compensation is a fixed amount. The CAA is explicit that it "is not linked to the price you paid for your ticket." It depends on the flight distance and, for long-haul flights, on how late you arrived:

Flight distance	Example (CAA)	Arrival delay	Compensation per person
Under 1,500 km	Glasgow–Amsterdam	3+ hours	£220
1,500–3,500 km	East Midlands–Marrakesh	3+ hours	£350
Over 3,500 km	London–New York	3 to 4 hours	£260
Over 3,500 km	London–New York	more than 4 hours	£520

Many tables show only "£220 / £350 / £520" and leave out the £260 row. A long-haul flight arriving 3.5 hours late gets £260, not £520.

The number that counts is arrival delay, not departure delay. The CAA says compensation may apply "if you arrive more than three hours late at your destination airport."

Connecting flights on one booking: the CAA measures distance "between the first and last airport in your booking," and only lateness at your final destination counts. Arriving late at the connection point doesn't count on its own. Separate bookings (self-transfer) get no compensation for a missed onward flight, although each flight keeps its own rights.

To find your band, work out the great-circle distance and apply the table. I built a free UK flight compensation calculator that does the distance maths and shows all four CAA bands, but you can check it by hand too.

3. Why was it late? The "extraordinary circumstances" test

Airlines don't have to pay compensation if the delay was caused by extraordinary circumstances, events outside the airline's control. The CAA's examples include:

weather incompatible with safe operation
strikes unrelated to the airline (airport staff, ground handlers, air traffic control, Border Force)
terrorism or sabotage, security risks, political or civil unrest
hidden manufacturing defects (e.g. a manufacturer recall that grounds a fleet)

Ordinary technical faults are generally not extraordinary. The CAA points to the Jet2 v Huzar judgment (Court of Appeal, 2014) and van der Lans v KLM (European Court, 2015), which found that technical problems, including early failure of a component, are not extraordinary circumstances.

A current example: after the NATS flight-planning failure on 8 September 2026, the CAA said that delays and cancellations caused by the incident, and its knock-on effects, "are likely to be 'extraordinary circumstances'". Passengers are therefore "unlikely to be entitled to compensation" for those disruptions. The CAA added that airlines must still look after passengers, and that its view is guidance, not a ruling on individual cases. It took the same view of a second NATS technical issue, at the Prestwick centre in Scotland, on 21 September 2026.

If you're unsure, claim anyway. The CAA says the airline "should explain to you the reason for the disruption" and, if it relies on extraordinary circumstances, "will need to clearly set out why."

Care and refunds apply even when compensation doesn't

Compensation is only one of your rights. While you wait, the CAA says your airline must provide care "regardless of the reason for the delay" once you've been held up beyond scheduled departure by:

2+ hours for flights under 1,500 km
3+ hours for 1,500–3,500 km
4+ hours for over 3,500 km

Care means food and drink, two calls or emails, and a hotel plus transport if you're delayed overnight. If the airline doesn't arrange it, you can book reasonable care yourself and claim it back. Keep itemised receipts.

If the delay reaches five hours, you can choose not to travel and get a refund for the flights you haven't taken. Don't choose this if you still want to travel.

Cancellations follow a different logic. You may be owed compensation if you were told less than 14 days before departure, depending on the cause and what replacement flight you were offered.

How to claim, step by step

Collect evidence: booking confirmation, boarding passes, the scheduled and actual arrival times, any messages giving the reason, and receipts.
Claim directly from the airline using its own claim form or process. The CAA recommends going to the airline first. It also notes that claim agencies typically charge a fee that "can often be a significant proportion" of the compensation, and that not all airlines will deal with a complaint made through a third party.
Escalate if needed. If you're unhappy with the final response, or the airline hasn't replied within eight weeks, go to the airline's Alternative Dispute Resolution (ADR) body if it belongs to one, or to the CAA's Passenger Advice and Complaints Team (PACT) if not. Note that PACT "cannot impose a decision on an airline", while CAA-approved ADR bodies can.
Court as a last resort. The small claims court is usually the right place, and GOV.UK explains how to make a court claim for money.

How long do you have? UK261 itself doesn't set a deadline. National limitation law applies instead. In England and Wales, contract claims generally have six years (Limitation Act 1980, s.5). In Scotland, the prescriptive period is generally five years (Prescription and Limitation (Scotland) Act 1973, s.6). Don't leave it late, and get advice if you're close to a deadline.

The short version

Arrived 3+ hours late on a covered flight, and the cause was within the airline's control? Then the CAA figures are £220, £350, £260 or £520 per person, depending on distance and, for long-haul, whether you were more or less than four hours late. Claim from the airline yourself first; it costs nothing.

This article is general information, not legal advice. Figures and quotes were checked against the CAA website on 28 September 2026.

Sources

UK CAA: Delays
UK CAA: Cancellations (coverage rules, 14-day notice)
UK CAA: Am I entitled to compensation? (extraordinary circumstances)
UK CAA: How to make a complaint (ADR, PACT, claim agencies)
UK CAA: Statement on passenger compensation following NATS disruption on 8 September (published 9 Sep 2026)
UK CAA: Statement on passenger compensation following NATS disruption on 21 September (September 2026)
GOV.UK: Make a court claim for money
Limitation Act 1980, s.5
Prescription and Limitation (Scotland) Act 1973, s.6

Disclosure: I run FlightRefundCalc, a free educational calculator. It is not a law firm or claims company, and it shows an optional, disclosed AirHelp referral that you never need to use.

Turning phone update policies into dates: precision, minimums and sources

Feroz Sheikh — Tue, 29 Sep 2026 05:43:33 +0000

"When does this phone stop getting security updates?" sounds like a single date. Once you try to store the answer for hundreds of models, it turns out to be at least four different kinds of fact. I run DevLifeCheck, which tracks this for phones, tablets, Chromebooks and routers. These are the modelling decisions that mattered most, using phones as the example.

Manufacturers publish four different shapes of data

A model-specific end date. Some manufacturers publish a table or spec line per model. Xiaomi's product software support page lists an end date for each Xiaomi, Redmi and POCO model, HMD lists one for its Nokia and HMD phones, and Samsung UK product pages carry a "Security Update Period (Valid until)" line. For the Galaxy A56 5G (SM-A566B) it says 31 March 2032.
A duration policy. Google says Pixel 8 and later get 7 years of OS and security updates "starting from when the device first became available on the Google Store in the US". Samsung announced seven generations of OS upgrades and seven years of security updates for the Galaxy S24 series. There's no date here. You calculate one from the policy and a start event.
A regulatory minimum. Under the UK's product security (PSTI) rules, brands such as OPPO, OnePlus, realme and vivo publish the end of a minimum security-update period for UK models. That is a floor, not a promised last patch.
Only a cadence. Samsung's security site lists models on monthly or quarterly update schedules, and vivo and HONOR publish similar lists. Being on the list tells you the phone is being patched now, not when that will stop. Apple publishes no end dates at all.

If you store all four in one end_date column, your data will be confidently wrong.

Store the meaning and the precision, not just the date

Each support claim gets a small bundle of fields. Simplified:

type SupportClaim = {
  date: string | null;            // ISO 8601, e.g. "2030-10-01"
  precision: "DAY" | "MONTH" | "YEAR" | "RANGE" | "UNKNOWN";
  meaning: "OFFICIAL_END" | "MINIMUM_COMMITMENT" | "ESTIMATE" | "UNKNOWN";
  evidence: "A" | "B" | "C" | "D" | "U"; // A = exact first-party date, B = first-party policy calculation
  region: string;                 // the market or model code the claim covers
  sourceUrl: string;              // first-party page it came from
  checkedAt: string;              // when that page was last checked
};

Precision matters most for policy-derived dates. Pixel 8 went on sale in the US in October 2023, so seven years lands in October 2030. The stored value is 2030-10-01 with MONTH precision, and the UI must never render it as "1 October 2030". A trimmed response from the public API shows the same idea:

{
  "slug": "google-pixel-8",
  "released": "2023-10-12",
  "securityEnd": "2030-10-01",
  "securityEndPrecision": "MONTH",
  "evidenceLevel": "B",
  "evidenceLabel": "Policy-derived",
  "supportCalculation": "Published policy applied to 2023-10-12; displayed at source-supported precision."
}

A published model date beats a calculation

The Galaxy A56 5G launched in March 2025 with up to six years of security updates, so the policy points to roughly March 2031. Samsung UK's page for the exact SM-A566B says 31 March 2032. When a first-party source gives a date for a specific model and market, it wins over a calculation, and the record keeps the region it applies to. The same phone sold elsewhere may have a different date.

Compute status when you read, not when you write

"Supported", "ending soon" and "ended" depend on today's date, so storing them means they go stale. DevLifeCheck derives status at request time from the date, its meaning and a 12-month "ending soon" window. Two rules matter most. When a minimum period has passed, the status becomes unknown, not ended, because many phones keep getting patches after their regulatory minimum and "ended" would be a false claim. And a date whose meaning is ESTIMATE never produces "supported" or "ended" on its own. The status stays unknown and the date is shown next to its label, so a reader can see how it was derived.

Unknown should stay unknown

Of the 712 phones DevLifeCheck currently tracks from 17 brands, 371 have a security end date. The rest have evidence (a cadence list, a UK minimum, an OS-upgrade count) but no final date, and they're shown that way. It's tempting to fill gaps with "the usual" value for a brand. Don't. A blank field with a source link is more useful than a plausible guess, because people use this data to decide whether to buy a used phone.

Try the data

The developer page documents a read-only API (/api/v1/devices, with a separate evidence endpoint per device) and a CSV export of the published catalog. Every row carries the precision, the date meaning and the source URL. Attribution is required.

If you've modelled end-of-life data for other hardware, I'd like to hear how you handled minimums versus final dates.

Disclosure: I build and maintain DevLifeCheck.