Thank you – that’s a real bug. Tried your prompt and looks like the dashboard drew only the first column. Thank you again, I’m fixing this as we speak – appreciate you taking the time to try this
Re: better model… yes, eventually I’ll upgrade – some context though on architecture: currently, the platform connects to Fred (800k economic series), Stooq (market prices), Edgar, and QuickBooks (w/ oAuth). In production, the info will be either solely pulled from a connector (i.e. QuickBooks, Xero, SAP, or other ERPs) or it will be uploaded via the Files panel, and it will not make up numbers (from model memory). That said, for this showing, if the prompt requests something the platform is not connected to, I allowed the model to fill in the numbers (from memory)… “This will not happen in production…” I left it "on" for this showing to see how people use the flow (and get feedback) vs. getting a “no data connection” type of response.
In terms of Claude (the app) vs. Ekselio.. there are a couple of things that make Ekselio different… execution runs in the browser (local first), so no server side data infrastructure, no warehouse, no copy of your ledgers etc - in accounting and corporate finance (the targeted vertical) this would be critical, considering the sensitivities around financial data - think financials, customer pricing (SKU level data), PII, etc. The only thing that leaves the browser is the planning request (column names only) – i.e. if you upload GL transaction details in the files panel (or pull it from quickbooks or another ERP via a connector) and then prompt it to build an aging schedule (30 days, 60 days, 90 days outstanding by customer), the schema / column names are sent to the LLM while the execution happens in the browser in your machine (privacy, etc).
The other thing is that you can save it, and next month can re-run it on fresh data with one click, with zero planning tokens(and deterministic in execution). Claude code (vs. Claude, the App) can also run locally with local tools but if the results are read or head it to understand the files, those rows leave the machine. Finally, you can export/build model in excel where the workflow SQL (from the nodes) are converted into M Code so it can run in excel with inputs and outputs with a check at the end (workflow output compared to the excel model output (M Code / Power Query)... this is still WIP, as some outputs show up as static right now) – but general idea is to support the workflow output with an excel output kind of like a certificate for audit purposes (i.e. can hand over the files to auditors).
There is also a desktop version that allows you to upload your excel models and it turns them into workflows (with inputs and outputs tying back to the excel model, full circle - wip at the moment); desktop only for now as it needs some fire power and running it on a server would defeat its purpose in terms of local first – the idea is that fp&a teams and accounting teams have a lot of institutional knowledge sitting in their monthly excel models (i.e. operating variance reports, warranty reserve calculations, inventory costing, etc) so there is a lot to unlock there, and automate with privacy, repeatability (zero tokens) and deterministic outputs in mind.