Drop in the K-1 package. Get the input workpaper back with every populated value tied to its source.
FinanceOCR reconstructs K-1 packages into an Excel workpaper in your supported tax software's input order. It handles supported K-1 statements, K-3s, QBI, §743(b), state detail and tiered structures locally in your browser. Anything it cannot establish is left unresolved and shown to you, not guessed.
Runs locally on your computer. Client content never leaves the device. You can inspect the network traffic yourself.
| Input destination | Value | Source |
|---|---|---|
| Box 1 · Ordinary business income | 84,210 | K-1 p.1 · Box 1 |
| Box 2 · Net rental real estate | (12,940) | K-1 p.1 · Box 2 |
| Box 13 · Code W | UNRESOLVED | Statement A · Note 3 |
| Box 20 · Code Z / QBI | 61,300 | Statement A · QBI section |
| §743(b) adjustment | (4,875) | Statement B · §743(b) |
| CA sourced amount | UNRESOLVED | CA schedule · 2 candidates |
Tested against known answers, not demos.
closed returns · K-1s · K-3s · supplemental statements · source pages
What actually means
independently adjudicated, in-scope mechanical exceptions were present in the benchmark. FinanceOCR surfaced .
Professional tax judgments, unsupported inputs and matters blocked by missing evidence are not counted as supported-scope misses.
Three steps. Nothing new to learn.
Drop in the K-1 package
PDFs as they arrived, or the package your software exported. One K-1 or forty, with statements, K-3s and state detail.
FinanceOCR runs locally, in minutes
Every supported value is placed on its input destination and tied to the page and location it came from. Anything it cannot establish stays unresolved.
Open the workpaper and resolve the short list
The Excel sheet follows your supported tax software's input order. Work straight down the screen, with the source beside each populated value and unresolved items separated for review.
Every expected relationship has to go somewhere.
FinanceOCR does not define success as "everything turned green." A relationship can be evaluated, blocked, unsupported or intentionally left to professional judgment. It cannot silently vanish from the denominator.
| Expected applicable mechanical relationships | |
| Evaluated | |
| Blocked by missing evidence | |
| Unsupported | |
| Professional-determination boundary | |
| Unaccounted |
ambiguous values. guessed.
| Uncertain fields encountered | |
| Surfaced or left unresolved | |
| Auto-filled despite uncertainty | |
| False-resolved items |
FinanceOCR treats uncertainty as an output state, not something to hide. If the supplied evidence does not establish one supported value, FinanceOCR does not invent one.
populated values. source-linked.
| PDF-derived values | artifact → page → source location |
| Spreadsheet-derived values | workbook → worksheet → cell/range → formula |
| Source provenance |
A reviewer never has to accept a FinanceOCR value simply because FinanceOCR produced it.
correct supported input destination.
| Populated supported fields | |
| Placed on the expected destination | |
| Placed on the wrong destination | |
| Destination accuracy |
Every wrong-destination event remains visible in the benchmark record and becomes a permanent regression case after remediation.
The reviewer gets signal, not another cleanup queue.
| Reviewer items presented | |
| Confirmed useful and actionable | |
| Unnecessary review items | |
| Reviewer-attention precision |
findings were surfaced beyond the original CPA answer key. were subsequently confirmed actionable. were not.
senior hours returned across benchmark matters.
Measured senior review time fell in the benchmark. How review time was measured
| Historical senior review time | |
| FinanceOCR-assisted review time | |
| Net review time returned | |
| Reduction |
- 37 K-1s
- 4 K-3s
- 9 state schedules
- 113 supplemental pages
- 2 entity tiers
- 146 minutes historical senior mechanical review
- Local processing: 6m 34s
- Reviewer items: 9
- Confirmed actionable: 8
- Professional determination: 1
- Reviewer time: 31 minutes
- 115 senior minutes returned
We try to make it wrong.
Adversarial scenarios passed, 0 silent false resolutions
- Identical amount, wrong entity
- Duplicate K-1
- Stale prior-year file
- Wrong tax year
- Conflicting PDF and tabular representation
- Wrong K-3 association
- Missing intermediate entity
- Hardcoded value that happens to tie
- Unreadable possible K-1
- Competing supplemental statements
- Duplicate source population
- Conflicting candidate workpapers
Remove the evidence, and FinanceOCR stops claiming the answer.
Required source support was deliberately removed from test matters. In every tested case, the affected conclusion weakened, became blocked or moved to an unresolved boundary rather than remaining falsely established.
Same files. Same engine version. Same result.
FinanceOCR's supported mechanical procedures are designed to produce the same result when the same inputs, procedure profile and engine version are used.
The Excel output cannot silently change the answer.
Every exported workpaper was reopened and compared to the canonical result: no lost values, no changed statuses, no duplicate populations.
Runs in minutes, on the machine.
Largest validated matter: K-1s · pages · artifacts
Client content never leaves your device.
Current release network test: bytes of client content transmitted.
| Account and authentication traffic | permitted |
| Application and version checks | permitted |
| Usage metering | permitted |
| Client documents | not transmitted |
| Extracted values | not transmitted |
| Client names | not transmitted |
| Findings | not transmitted |
| Source hashes | not transmitted |
{
"matter_count": 1,
"entitlement_id": "ent_…"
}
Don't take our word for it.
Open FinanceOCR, load the supported workspace and inspect the browser's network traffic while processing a test package. Your IT team should be able to verify that client-private content never appears in an outbound request.
See the verification procedureHere is exactly what we do not support.
Support is listed by tax year, artifact, procedure and renderer. Anything outside it is reported as unsupported in the workpaper, never filled. Scanned handwritten documents are not supported.
See the supported-input matrixWe publish what FinanceOCR gets wrong.
Supported-scope failures are preserved as reproducible cases. A fixed failure is not deleted from the history; it becomes a permanent regression test.
See what it missedEverything your firm needs before approval.
Designed to simplify vendor review. FinanceOCR provides a one-page data-flow and vendor-security summary for the firm's WISP and vendor-oversight process.
Data Protection Agreement
Available before client work begins.
WISP vendor summary
One-page description of FinanceOCR's local-processing architecture for the firm's vendor file.
Insurance certificate
Current ACORD certificate available before purchase.
Data-flow map
Exactly what stays local and what limited non-client traffic leaves the device.
Supported-input matrix
Tax year, artifact, procedure and renderer support listed explicitly.
Verification results
Frozen benchmark, known limitations and current release receipt.
Insurance
Professional and cyber coverage maintained.
| Carrier | Berkshire Hathaway Direct Insurance Company |
| NAIC | 10391 |
| Certificate date | January 28, 2026 |
| Professional liability limit | $2,000,000 |
| Cyber liability limit | $1,000,000 |
Current certificate available to prospective firms before purchase. Coverage is subject to the policy's terms, exclusions, conditions and applicable limits.
Four guarantees.
The legal terms define each one precisely. These are the plain versions.
Value guarantee
If your actual supported use prices below your Season payment at our published à-la-carte rates, choose the difference back or 125% of the difference as renewal credit.
Accuracy guarantee
If FinanceOCR fills a supported field that should have been left unresolved, that matter does not count and we correct the defect.
Support guarantee
If a supported document type or layout fails to process correctly, FinanceOCR fixes the supported-path defect within two business days from February 1 through April 15. A matter counts only once it processes correctly.
Continuity guarantee
If FinanceOCR ceases operating during your paid term, unused Season value is refunded and everything already generated remains yours.
$750, then $3,500, then Season.
Each step credits in full toward the next.
One completed K-1-heavy matter you already know. Run FinanceOCR blind against the source package and compare the workpaper with your completed work.
If it doesn't hold up to your review, don't continue.
Credits to Live Run or Season.
Five live K-1-heavy matters through your actual workflow. Same accuracy guarantee on every matter.
Your $750 Benchmark credits in full. Balance after Benchmark: $2,750.
- 15 K-1-heavy matters
- Intake on up to 40 spring returns
- Up to 8 new-client prior-year conversions with supported carryovers and depreciation
- 1 basis rebuild
- Supported tax-software-ordered Excel workpapers
- Source provenance on every populated supported value
- Through October 15
After Benchmark: $14,250 remaining.
After Live Run: $11,500 remaining.
| À la carte | |
| 15 K-1 matters × $750 | $11,250 |
| 40 intake matters × $250 | $10,000 |
| 8 conversions × $750 | $6,000 |
| 1 basis rebuild | $2,500 |
| Maximum included menu value | $29,750 |
Only Benchmark and Live Run credit toward Season. À-la-carte purchases do not.
Founding firms renew next season at $15,000 while remaining within the same capacity band. Standard Season for the next cohort: $20,000.
FinanceOCR records a matter count for billing and the value guarantee. Only the count and the entitlement it is charged to are transmitted; no client names, filenames, documents, values, extracted text, findings, hashes or other client-derived content are transmitted.
Built by a small team. Checked by a tax partner.
FinanceOCR was founded by Emmanuel Kyumba after five years working in state and local tax technology and risk, reconciling multistate workpapers and correcting manually keyed tax data across professional tax workflows.
The recurring problem was simple: a number could tie while still being on the wrong line, copied from the wrong version or unsupported by the source package.
FinanceOCR was built around the opposite rule: every populated value should be traceable, and uncertainty should remain visible.
Emmanuel built FinanceOCR with two software engineers, who built the extraction engine, the parsers and the local runtime, and a practicing tax partner, who validates FinanceOCR's output against real returns before each release.
Product, verification methodology, and the firms we work with.
Extraction engine, parsers, tax-software renderers and the local runtime.
Checks FinanceOCR's output against real returns before each release.
Give us the return most likely to break it.
Pick one closed K-1-heavy return your team already knows. Give FinanceOCR the source package, not your completed answer. Compare every populated value and every unresolved item against your own work.
If FinanceOCR does not hold up to your review, stop there.
Drop in the return package. Get back only what your reviewer needs to decide.
FinanceOCR works locally through the supplied return, workpapers and supporting files, completes the supported mechanical review automatically, and returns what differs, what support is missing and what still requires professional judgment.
Runs locally on your computer. Client files and review content stay on the device.
The bottleneck is senior review time.
Preparation has gotten faster. Review has not.
A prepared return can still arrive with multiple workpapers, competing file versions, K-1s, trial-balance support, state schedules and unresolved dependencies. Before the reviewer can apply judgment, someone still has to determine what ties, what changed, which support is present and what remains unexplained.
Senior reviewers should not be reconstructing packages.
Why does Schedule L differ? Which K-1s feed this amount? Where did this adjustment come from? What document is still missing?
They should not be spending their first hour figuring out what changed, what's missing and which file governs.
FinanceOCR performs the supported mechanical work before the reviewer opens the package, then hands back the exceptions and evidence boundaries that actually require attention.
Give FinanceOCR the package. Get back the review queue.
The entire workflow is three steps. No tools to operate in between.
Submit the package
Select the return type, tax year and files exactly as they exist today.
- No reorganizing
- No procedural setup
- No mapping exercise in normal cases
- No need to know which workbook is final
FinanceOCR does the work
The local agent determines which supported procedures apply and executes them automatically against the supplied evidence.
- Inventories files, detects competing versions
- Replays supported calculations
- Traces source relationships
- Reconciles mapped figures
- Identifies missing dependencies
The user does not choose tools.
Your reviewer starts with the exceptions
FinanceOCR notifies you when the reviewer packet is ready. The reviewer sees:
It should feel like handing work to someone, not learning another tax application.
FinanceOCR is designed as a service delivered through software. Your team does not select checking modules, build source chains, configure workflows or decide which procedure should run next.
Submit the package and step away. FinanceOCR determines what supported work can be completed, runs it locally, and notifies you when the reviewer packet is ready.
What happens when the package itself cannot tell you which file is final?
HarborPoint demonstrates the product philosophy better than a clean-package example. FinanceOCR did not choose the newest file or the one named FINAL. It preserved every candidate, established which figures tied to the filed returns and stopped where the evidence stopped.
FinanceOCR preserved every candidate. It established which figures tied to the filed returns, replayed the supported adjustment arithmetic, and stopped where the evidence stopped.
Tested blind against returns a CPA had already worked.
31 prior-year Form 1040s, already reviewed and closed by a CPA. FinanceOCR received the same packages without the completed answers. The reviewer packet was then compared against what the CPA's review had found.
Client identities, amounts and firm details are redacted. Three exceptions were not caught; each is described in the case study so you can judge whether the gap matters for your packages.
Read the redacted case study →What FinanceOCR can clear before your reviewer starts
Coverage depends on the files supplied and the procedures currently supported. FinanceOCR runs every supported procedure the package allows and explicitly identifies where the evidence or calculation family falls outside coverage.
File inventory, duplicates, unreadable files, unsupported artifacts, conflicting candidate versions and missing external dependencies.
Mapped return figures traced to supported workpapers and independently compared or reperformed where possible.
Schedule L and supplied trial-balance relationships where supported.
Supported M-1/M-2 arithmetic, workpaper ties and unresolved reconciling items.
Supported K-1 aggregation and cross-document comparisons where a mechanically identifiable relationship exists.
Supported beginning balance + activity + ending balance relationships.
Supported apportionment, state adjustments, return-to-workpaper ties and candidate-version comparisons.
Your reviewer gets the exceptions, not the cleanup.
The detailed verification record remains underneath. The first thing your reviewer sees is the small set of items that still need a human.
Autonomous does not mean cloud-hosted.
The workflow agent and review procedures execute locally against the files already on your computer. Client-private return content is not sent to FinanceOCR servers or remote AI services.
Return files, extracted text, formulas, values, findings and review records remain on the device.
FinanceOCR does not send client-private review content to remote AI services.
Review execution is checkpointed locally. Continue working elsewhere and FinanceOCR notifies you when the reviewer packet is ready.
Here is exactly what FinanceOCR supports, and what it does not.
Support is versioned by tax year, K-1 type, procedure and renderer. A package may contain both supported and unsupported branches. FinanceOCR processes what is supported, leaves everything else unresolved, and reports the boundary explicitly.
K-1 workpaper capabilities
Only real production states are shown. A capability is listed as production supported only after it passes acceptance in the current release.
| Capability | Status |
|---|
Tax software renderer matrix
A cell turns green only once that tax year, K-1 type and renderer pass acceptance.
| Tax software | 2025 | 2026 | K-1 types | Status |
|---|
FinanceOCR never changes canonical tax data to fit a vendor mapping. If a supported canonical value has no verified destination, the destination remains unresolved.
Mechanical pre-review coverage
The procedure registry below applies to the mechanical pre-review product for larger firms.
Return families
| Return family | Engine scope | Status |
|---|---|---|
| Complex Form 1040 | Full mechanical pre-review profile | PRODUCTION_SUPPORTED |
| Extended Form 1040 | Full mechanical pre-review profile | PRODUCTION_SUPPORTED |
| Form 1065 | Mechanical review profile | PRODUCTION_SUPPORTED |
| Form 1120-S | Mechanical review profile | PRODUCTION_SUPPORTED |
| Form 1120 | Mechanical review profile | PRODUCTION_SUPPORTED |
| Multistate / state returns | Structural and apportionment procedures | PRODUCTION_SUPPORTED |
| Amended / revised packages | Revision comparison and lineage | PRODUCTION_SUPPORTED |
Status is determined by the production capability registry. A return family being recognized does not imply every procedure within that family is supported; the procedure-level status below governs.
Pass-through review
Schedule K-1 handling is the deepest layer of the engine. FinanceOCR is designed to support filed K-1 PDFs, tabular K-1 exports, multiple K-1s in one matter, K-1 source-item identity across duplicate representations, population completeness, K-1-to-return tracing, prior-year continuity, missing / late / unreadable / unsupported K-1 states, ambiguous mappings, duplicate detection and tiered-entity cases.
| K-1 procedure | Status |
|---|---|
| K-1 PDF ingestion | PRODUCTION_SUPPORTED |
| K-1 tabular ingestion | PRODUCTION_SUPPORTED |
| K-1 source-item identity | PRODUCTION_SUPPORTED |
| K-1 population inventory | PRODUCTION_SUPPORTED |
| K-1 aggregation | PRODUCTION_SUPPORTED |
| K-1 → return-line trace | PRODUCTION_SUPPORTED |
| Prior-year K-1 continuity | PRODUCTION_SUPPORTED |
| Duplicate K-1 detection | PRODUCTION_SUPPORTED |
| Missing / late / unreadable / unsupported K-1 states | PRODUCTION_SUPPORTED |
| Ambiguous-mapping detection | PRODUCTION_SUPPORTED |
| Tiered-entity handling | PRODUCTION_SUPPORTED |
Advanced pass-through procedures
K-3
Basis adjustments
QBI
Shareholder / partner basis
Suspended losses
Foreign accounts
Core package review
The non-K-1 layers run on every package and are what make the reviewer packet possible: they establish what was supplied, which files compete, what ties, and where the evidence stops.
Package integrity
Formula and source tracing
State and revision
Review modes and limits
Input formats
File support and procedure support are separate questions. A file being readable does not mean every procedure applies to it; a procedure being supported does not mean every file layout feeds it. FinanceOCR works with supported exported layouts from the tax systems below. Native integration is not required for the core review workflow.
.xlsx.xls.xlsm— read as data; macros are never executed.csv.tsv.txt
- Supported federal return PDFs
- Supported Schedule K-1 PDFs
- Supported Schedule K-3 PDFs
- Supported state-return PDFs
- Supporting PDF schedules where a parser exists
- Scanned / image-only PDFs — retained in the package and explicitly bounded where no trusted text layer exists
- CCH Axcess
- GoSystem RS
- ONESOURCE
- UltraTax
- ProConnect
Capability-state legend
Every procedure above carries the state assigned in the production capability registry. Only PRODUCTION_SUPPORTED procedures are claimed for production review.
Four distinct builds. Three reproduce the California filing. All four reproduce Illinois. The supplied evidence still does not establish which workbook governed.
FinanceOCR did not choose the newest file or the one named FINAL. It preserved every candidate, established which figures tied to the filed returns, replayed the supported arithmetic and stopped where the evidence stopped.
The package
Five physical candidate files reduced to four distinct builds because HP_Final_Copy_For_Robert.xlsx was byte-identical to HarborPoint_Sales_Workpaper_FINAL.xlsx.
File inventory
| File | Disposition |
|---|---|
| HarborPoint_CA_Final_Return.pdf | Consumed — filed CA figures |
| HarborPoint_IL_Final_Return.pdf | Consumed — filed IL figures |
| HarborPoint_Sales_Population_TY2025.csv | Consumed — current-year population |
| HarborPoint_Combined_ProForma.xlsx | Consumed — entity roster |
| HarborPoint_Bridge_BROKEN.xlsx | Consumed — adjustment bridge |
| HarborPoint_Sales_Workpaper copy.xlsx | Candidate build |
| HarborPoint_Sales_Workpaper_FINAL_v2.xlsx | Candidate build |
| HarborPoint_Sales_Workpaper_FINAL.xlsx | Candidate build |
| HP_Final_Copy_For_Robert.xlsx | Byte-identical duplicate of …_FINAL.xlsx |
| HarborPoint_Sales_Workpaper.xlsx | Candidate build |
| HarborPoint_Sales_Population_TY2024.csv | Excluded by period — TY2024 |
| HarborPoint_Payroll_Unrelated.xlsx | Outside receipts-sourcing scope |
| HarborPoint_Sourcing_Memo_SCAN.pdf | Boundary — supplied but no machine-readable text layer |
| FIRM_QUESTION_DISPLAY_ONLY.txt | Display context only — zero engine effect |
The engine retained the TY2024 population, payroll workbook, scanned memo and display-only context in the package rather than silently discarding them. The scanned memo was specifically recorded as unreadable for established mechanical evidence.
Candidate comparison
| Candidate | CA numerator | CA filed tie | IL numerator | IL filed tie | Governing? |
|---|---|---|---|---|---|
| Sales_Workpaper copy.xlsx | $48,700,000 | Numerator + denominator + factor | $8,455,000 | Numerator + denominator + factor | NOT ESTABLISHED |
| Sales_Workpaper_FINAL_v2.xlsx | $48,700,000 | Numerator + denominator + factor | $8,455,000 | Numerator + denominator + factor | NOT ESTABLISHED |
| Sales_Workpaper_FINAL.xlsx | $48,700,000 | Numerator + denominator + factor | $8,455,000 | Numerator + denominator + factor | NOT ESTABLISHED |
| Sales_Workpaper.xlsx | $48,660,000 | Denominator only | $8,455,000 | Numerator + denominator + factor | NOT ESTABLISHED |
Every candidate uses the same $101,052,000 denominator. Three candidates fully reproduce the CA filing; the fourth does not reproduce the CA numerator. All four reproduce the IL filed figures. None of those facts establishes which workbook was actually governing.
Adjustment bridge
The arithmetic replays exactly, so the correct result is arithmetic replayed, support not established — not "adjustment verified." The $87,000 sourcing adjustment rests on a workbook the package references but does not contain.
The missing workbook is a real unresolved external dependency in the technical record: it is the assignment basis reaching the scoped chain, and no candidate build can be established as governing until it is produced or the adjustment is otherwise supported.
Population result
The jurisdiction flag sums do not reconcile to the candidate-build numerators. The population therefore establishes dimensions and assignments, not the full reported amount.
Entity-roster boundary
FinanceOCR states the difference. It does not choose which total is correct.
Reviewer queue
Three primary questions remained after mechanical reconstruction. Each is a professional determination, not a calculation.
Four structurally distinct candidate builds were supplied. Filename markers such as FINAL and FINAL_v2, timestamps, authorship and filed-number agreement do not independently establish governance.
The arithmetic replays, but Missing_Sourcing_Support.xlsx was referenced and not supplied.
The combined roster carries $101.407M while every candidate denominator is $101.052M. The supplied evidence does not resolve the $355K difference.
Secondary evidence boundaries
- HarborPoint_Sourcing_Memo_SCAN.pdf supplied but not machine-readable.
- TY2024 population retained but excluded from the TY2025 procedure.
- Payroll workbook retained but outside the receipts-sourcing issue.
- Population completeness against an external federal/book-revenue anchor was not established.
FinanceOCR established what the supplied package mechanically supports, preserved the competing builds, reproduced the supported arithmetic, and stopped where additional evidence or professional judgment was required.
31 prior-year 1040s. 2,317 items traced. Three to the wrong line. 38 of 41 exceptions caught.
A CPA had already reviewed and closed every return in this set. FinanceOCR received the same packages without the completed answers, and its reviewer packet was compared against what the CPA's review had found.
How the benchmark was run
Blind. FinanceOCR was given the return package, workpapers and supporting files exactly as the firm had them. It was not given the CPA's review notes, the exception list or the final signed-off figures.
Prior-year, already closed. All 31 returns were prior-year Form 1040s that a CPA had fully worked. That makes the CPA's findings the answer key: every exception FinanceOCR reports either matches something the CPA found, or it does not.
Compared after the fact. Once the reviewer packet was produced, each traced item and each reported exception was scored against the CPA's review.
- Client and taxpayer identities
- Dollar amounts on individual returns
- Firm name and location
- Return-level detail that could identify a client
The counts and rates are the original benchmark figures. Nothing has been re-weighted or excluded.
Line tracing
Every traced item in the reviewer packet carries the source file, worksheet, cell or document reference used to make the trace, so the reviewer can check any individual item in seconds. The three mis-traced items were visible as traces in the packet; they were not silent.
Exception detection
| Measure | Count | Rate |
|---|---|---|
| Items traced | 2,317 | — |
| Correct line | 2,314 | 99.87% |
| Wrong line | 3 | 0.13% |
| CPA exceptions | 41 | — |
| Caught | 38 | 92.7% |
| Missed | 3 | 7.3% |
The three that were missed
Three CPA-identified exceptions did not appear in the reviewer packet. In each case the question is the same: was the exception mechanically supportable from the supplied files, or did it depend on knowledge the package did not contain?
[What FinanceOCR did report on this return, and the evidence boundary it stated.]
[What FinanceOCR did report on this return, and the evidence boundary it stated.]
[What FinanceOCR did report on this return, and the evidence boundary it stated.]
FinanceOCR does not decide whether a tax treatment is correct. Exceptions that turn on professional judgment rather than the supplied records are reported as professional-determination boundaries, not resolved.
Run the same benchmark on your own returns.
Give FinanceOCR a closed return your team has already reviewed, without the completed answer, and compare the reviewer packet against what your review found. No charge if it misses a material mechanical exception supported by the supplied records within the agreed scope.
closed returns. K-1s. pages. Run blind.
A CPA had already completed each return. FinanceOCR received the same source packages without the completed answers. Results were scored afterward against independently adjudicated mechanical findings and the CPA's completed work.
The benchmark system
| Closed returns | |
| K-1s / K-3s | / |
| Supplemental statements | |
| Source pages / artifacts | / |
| Supported-scope reference exceptions / surfaced / missed | / / |
| Populated fields / wrong destination | / |
| Uncertain fields / auto-filled | / |
| Reruns / drift | / |
| Evidence-removal tests / failures | / |
| Adversarial scenarios / passed | / |
| Exported workpapers / parity failures | / |
How review time was measured
Historical senior review time is the time the CPA recorded for mechanical review of each matter when it was originally worked: across the benchmark. FinanceOCR-assisted review time is the time the reviewer spent working the FinanceOCR workpaper and its unresolved items to the same sign-off standard: . The difference, , is reported as time returned; the reduction is .
This is measured review time in the benchmark, not a speed claim for every firm.
We publish what FinanceOCR gets wrong.
Supported-scope failures are preserved as reproducible cases. A fixed failure is not deleted from the history; it becomes a permanent regression test.
What FinanceOCR missed
of supported mechanical exceptions was not surfaced.
| Miss 1 — class | Published from the benchmark record |
| What the reference review identified | Published from the benchmark record |
| What evidence FinanceOCR had | Published from the benchmark record |
| Why it failed | Published from the benchmark record |
| Materiality | Published from the benchmark record |
| Change made | Published from the benchmark record |
| Permanent regression fixture | Published from the benchmark record |
| Current status | Published from the benchmark record |
An earlier, smaller benchmark on 31 prior-year Form 1040s is kept on record. Read the 31-return benchmark
The website cannot claim more than the current release has proven.
Every figure on this site is read from the release's verification manifest. This page shows which release it is, how to check the network claims yourself, and every consequential change since.
Release receipt
| Verification date | |
| Engine version | |
| Build hash | |
| Procedure profile | |
| Browsers | |
| Benchmark manifest hash |
Network verification procedure
Your IT team can confirm that client-private content never appears in an outbound request. It takes about ten minutes.
- Open Chrome or Edge, press F12 and select the Network tab. Tick "Preserve log."
- Open FinanceOCR and sign in. You will see authentication, entitlement, version-check and static-asset requests. These are expected.
- Clear the log, then load a test K-1 package and run it to completion.
- Review every request made during processing. The only permitted request is the usage event, whose body contains two fields:
matter_countandentitlement_id. - Search the log for a distinctive value from your test K-1 (a name, EIN fragment or amount). It should not appear anywhere.
Current release network test: bytes of client content transmitted
known unresolved supported-path defects in the current validation release
| Supported-path defects discovered during validation | |
| Reproduced and fixed | |
| Added to permanent regression | |
| Currently open |
Guarantee record
Commercial guarantee statistics begin with the first paid Season cohort.
Changelog
Consequential changes only: renderer promotions, supported-path fixes and new regression cases.
Client file content stays on your device.
FinanceOCR separates ordinary website and account services from the private review workspace. Client file content is processed inside the browser and is not transmitted to FinanceOCR for analysis.
Two environments
Website and account services
Standard web services. Information here is transmitted to FinanceOCR’s servers in the ordinary way.
- Benchmark support check — return type, tax year, tax software and package shape; no client identifiers
- Account access — email address and authentication
- Payment — processed by a third-party provider; card details are not stored by FinanceOCR
- Usage metering — matter count and entitlement ID only
- Contact messages — messages you send through contact forms
Private review workspace
Runs inside your browser. Client file content does not leave your device during supported analysis.
- Selected files — read locally; not uploaded
- Extracted text and tables — produced and held in browser memory
- Formulas and cell values — analyzed locally
- Calculations and findings — produced by the FinanceOCR engine running in your browser
- Hashes and fingerprints — derived locally; not transmitted
- Reviewer decisions — stored in local browser storage
- Exported workpapers — written to your device via the browser’s download mechanism
How the workspace operates
matter_count and entitlement_id. None of these contain client names, filenames, documents, values, extracted text, findings, hashes or other client-derived content.No cloud fallback
FinanceOCR does not use a hidden cloud fallback. If the browser, file type, calculation or dependency is unsupported, the affected branch is marked incomplete, unsupported or blocked.
The reviewer can provide another supported source, narrow the scope or stop the run. Client files are not silently uploaded to complete an operation that cannot be done locally.
Documents are treated as data, not instructions
FinanceOCR does not execute VBA, workbook macros, embedded scripts or document instructions. It does not automatically retrieve external workbook dependencies merely because a workbook references them.
Files are analyzed as data within the supported scope.
What leaves the device — and what never does
- Account authentication
- Entitlement validation
- Application and version checks
- Static application assets
- Matter count
- Entitlement ID
- Ordinary billing and account events
- Client files
- Filenames and file paths
- Taxpayer and client names
- Extracted text
- Extracted tables
- Tax values
- Formulas
- Source mappings
- Findings
- Reviewer decisions
- Locally derived hashes and fingerprints
- Exported workpapers
Current network verification result: bytes of client content transmitted.
{
"matter_count": 1,
"entitlement_id": "ent_…"
}
What your IT team can verify
See the step-by-step network verification procedure
FinanceOCR is designed so the local-processing claim can be tested. An IT reviewer can inspect network activity during a review and confirm that client-private content is not transmitted.
The production workspace uses a restricted set of permitted network requests for non-client functions such as authentication and entitlement. Client files, extracted content, formulas, values, findings and client-derived fingerprints are excluded from those requests.
- Which network requests the application makes during a review session
- That client file content is not included in those requests
- That no remote AI endpoint receives the client package
- That unsupported work does not trigger a hidden cloud-upload fallback
- That client files are processed inside the browser environment
Local storage and deletion
FinanceOCR may keep local review state in the browser so you can pause, resume, resolve a question, add supplemental evidence and export the review record.
If the selected files change between sessions, FinanceOCR treats that as a new revision rather than continuing against a different package.
Browser storage should not be treated as permanent archival storage. If the tab closes before a local checkpoint is saved, affected work may need to be rerun.
Specific environments
If you operate on an air-gapped device, have network restrictions, or have compliance constraints that affect browser-based applications, contact us before starting an evaluation. We will advise whether the workspace can operate within those constraints.
Data-handling and privacy questions: privacy@financeocr.com
Talk to the person who built it.
FinanceOCR was founded by Emmanuel Kyumba after five years working in state and local tax technology and risk, reconciling multistate workpapers and correcting manually keyed tax data across professional tax workflows.
Do not email client files or taxpayer identifiers. Client files are selected inside the local workspace and never leave your device.
Want to test it on a return you already know?
The fastest way to evaluate FinanceOCR is a closed-return benchmark: pick one completed K-1-heavy return, give FinanceOCR the source package without your answer, and compare every populated value and unresolved item against your own work. If it doesn't hold up, stop there.
Open your FinanceOCR workspace.
Sign in to activate or return to your private review workspace. Client files are selected inside the workspace and processed locally.
FinanceOCR signs you in with a one-time link sent to your work email. There is no password to set or reset.
Continue to sign inChrome and Edge are the supported production browsers for the workspace. Compatibility is checked before any client file is selected.
There is no password to reset.
FinanceOCR signs you in with a one-time link sent to your work email each time.
Privacy Policy
Who we are
FinanceOCR is operated by Emmanuel Kyumba. This policy explains what information we collect, how we use it, and how you can contact us about it. References to "FinanceOCR," "we," "us" or "our" mean the operator.
Client file content stays on your device
The private review workspace runs inside your browser. Files you select for analysis are read and processed locally on your device. Client file content — including extracted text, formulas, values, findings and derived fingerprints — is not transmitted to FinanceOCR or to remote AI services as part of the supported analysis.
This is a technical architectural commitment. The data handling page describes it in detail and explains what your IT team can verify.
Information we collect
We collect the information you provide when you:
- Submit an evaluation request — name, work email, firm, a brief matter description and file types
- Send a contact message
- Create or authenticate an account
- Accept an evaluation and initiate payment
We may also collect standard server log data (IP address, browser type, pages visited, timestamps) for security, debugging and operational purposes.
How we use the information
- To confirm evaluation scope and communicate the next step
- To deliver and support the review workspace
- To process payment through a third-party provider
- To respond to contact and support messages
- To maintain the security and integrity of the service
We do not sell your personal information. We do not use it to train AI models.
Payment
Payment is processed by a third-party payment provider. FinanceOCR does not store payment card numbers or equivalent payment credentials. The payment provider operates under its own privacy policy.
Third-party services
The website uses Google Fonts for typography. Standard web analytics may be collected by the hosting infrastructure. We do not currently use third-party advertising or tracking services.
Data retention
We retain account and evaluation records for as long as the account is active and for a reasonable period afterward for legal and operational purposes. Contact information from closed evaluations is retained for a limited period consistent with ordinary business recordkeeping. You can request deletion at any time by contacting us at the address below.
Your rights
Depending on where you are located, you may have rights to access, correct, delete or restrict the processing of your personal information. To exercise any of those rights, contact us at privacy@financeocr.com. We will respond within a reasonable time.
Cookies
The website uses cookies or similar local storage mechanisms for session management and application functionality. We do not use tracking or advertising cookies.
Changes to this policy
We may update this policy from time to time. Material changes will be noted with an updated date at the top of this page. Continued use of the service after a material change constitutes acceptance of the revised policy.
Contact
For privacy questions or rights requests, contact us at:
FinanceOCR · Los Angeles, CA
Terms of Service
Who these terms apply to
These Terms of Service govern your use of the FinanceOCR website and private review workspace operated by Emmanuel Kyumba ("FinanceOCR," "we," "us," "our"). By requesting an evaluation or using the workspace, you agree to these terms. If you do not agree, do not use the service.
What FinanceOCR is
FinanceOCR is a mechanical analysis tool. It reconstructs and compares tax and regulatory workpaper calculations using the files you supply. It identifies formula changes, traces arithmetic, reconciles stated figures, names evidence gaps and prepares targeted evidence requests.
FinanceOCR does not determine tax positions, legal conclusions, professional opinions or regulatory outcomes. All findings are mechanical descriptions of what the supplied records establish. Professional judgment, method selection, and decisions about tax positions remain with you.
Evaluation agreement
Each evaluation is governed by a scope agreement confirmed by email before the run begins. That agreement specifies:
- The calculation family and supported scope
- The files you will supply
- The deliverables FinanceOCR will produce
- The acceptance criteria and charge conditions
Payment becomes due only after you accept the agreed deliverables. If the analysis materially fails to meet the agreed scope — by missing a material issue supported by the supplied records, collapsing an unresolved explanation, or asserting unsupported facts — the charge does not apply. No subscription or annual commitment is required.
Your responsibilities
- You are responsible for the files you supply and for ensuring you have the right to use them for this purpose
- You remain responsible for all professional, legal and regulatory judgments arising from the matter
- You are responsible for verifying FinanceOCR’s findings against the source records before relying on them
- You must not use FinanceOCR to produce outputs you represent as independent professional opinions if they are not
- You must not misrepresent FinanceOCR’s mechanical findings as professional advice, legal conclusions or regulatory determinations
Acceptable use
You may use FinanceOCR for legitimate professional purposes including workpaper review, controversy preparation, revision comparison and evidence analysis, within the supported scope.
You must not:
- Attempt to reverse-engineer, extract or copy the FinanceOCR engine or processing logic
- Use the service to produce fraudulent, fabricated or misleading analysis
- Attempt to circumvent any technical restriction or access control
- Use automated means to access the service in ways that damage or impair it
Intellectual property
FinanceOCR and its underlying technology, presentation and branding are owned by Emmanuel Kyumba. Nothing in these terms transfers ownership of the service to you.
You retain ownership of the files you supply. You grant FinanceOCR a limited license to process them locally for the purpose of producing the agreed evaluation. That license extends only to the local processing necessary to complete the agreed scope.
The analysis records and review outputs FinanceOCR produces for your evaluation are provided for your use in connection with the agreed matter.
No professional advice
FinanceOCR is not a lawyer, tax advisor, accountant, regulatory expert or professional of any kind. Nothing it produces constitutes legal, tax, accounting or professional advice. Do not rely on FinanceOCR’s outputs as a substitute for qualified professional advice on your specific situation.
Limitation of liability
To the maximum extent permitted by applicable law, FinanceOCR’s liability in connection with any evaluation or use of the service is limited to the amount you paid for that specific evaluation. FinanceOCR is not liable for indirect, consequential, incidental or punitive damages arising from your use of the service.
FinanceOCR does not warrant that the service is error-free, that outputs are accurate, complete or suitable for any particular purpose, or that the service will be available without interruption.
Privacy
Your use of the service is also governed by the Privacy Policy, which is incorporated into these terms by reference.
Changes to these terms
We may update these terms from time to time. Material changes will be noted with an updated date at the top of this page. Evaluations in progress under a confirmed scope agreement are governed by the terms in effect at the time that agreement was confirmed.
Governing law
These terms are governed by the laws of the State of California. Any dispute arising under these terms shall be resolved in the courts of Los Angeles County, California, unless otherwise required by applicable law.
Contact
That page is not in the package.
The address may have changed or never existed. Nothing was lost on your side.