INVIZ.tv / Reporting sources / System 03 of 04
2023Recorded work
QuickBooks uploads and creator reporting data
Keep the original accounting export, prepare its transactions for reporting and show when the client last uploaded data.
- Noah’s contribution
- Configured and explained the client-linked upload process; corrected destination searches, mappings and folder paths until test data populated.
- Historical stage
- Configured historical reporting handoff and sample-data population; creator statements remained discovery/proposed work.
- Part of the business
- INVIZ.tv overview ↗
- ClickUp
- Typeform
- QuickBooks exports
- XLSM / XLSX
- Google Drive
- Google Sheets
- Make
- Google Data Studio
Inside this system
The workflow
The handoffs
inside the work.
Follow the main path and its branches. Select a step for context; the account below explains what was built, tested or planned.
- Active client accounting view
Give accountants client-specific upload/dashboard links and last-upload information. - Accountant submits QuickBooks export
Upload the expected workbook using the form associated with the client. - Retain original export
Store the uploaded source workbook in the client’s retained-export location. - Resolve the reporting destination
Search the correct folder and require a single matching reporting sheet. - Restructure transaction rows
Parse the expected worksheet into the separate reporting dataset. - Check overlapping date ranges
The described duplicate check addresses transactions repeated across uploads. - Accumulated creator-reporting data
Keep flattened transactions available for dashboard consumption. - Last-report-uploaded date
Update the client’s visible freshness field when a report is submitted. - Dashboard reporting view
Use the accumulated dataset for the demonstrated summaries and reporting views.
Key records
The information
that carries forward.
| Record | Information | Purpose |
|---|---|---|
| Original report | Uploaded QuickBooks export retained in the client workspace. | Preserve the source behind the reporting rows. |
| Creator reporting data | Restructured transaction lines accumulated for the dashboard. | Support reporting across successive uploads. |
| Upload freshness | Last-report-uploaded date and the client’s upload/dashboard links. | Help accountants identify which client reports need updating. |
Inside the system / 01
Turn an accounting task into a repeatable handoff
The accountant-facing instructions began in ClickUp’s client list. An accounting view showed active clients and their individual upload links, placing the recurring report task alongside the relationship record. The example used an XLSM workbook whose first sheet contained export instructions and whose second sheet held the information to parse.
After submission, the workflow stored the original QuickBooks export and restructured its reporting rows into a separate sheet used by the dashboard. The original file remained available in the client folder. This preserved a useful distinction between the source accounting artifact and the flattened dataset intended for reporting.
Inside the system / 02
Handle freshness, overlaps and destination ambiguity
A last-report-uploaded field updated when a new report was submitted. Noah also described a duplicate check for overlapping date ranges, a practical issue when successive monthly exports contain some of the same days. The recording explains that intended protection; it does not include a comprehensive reconciliation or adversarial duplicate test.
The build session makes the destination checks concrete. Noah searched within the appropriate folder for the reporting sheet, required a single matching result before continuing and corrected a mistaken parent-folder path for retained exports. A delay accommodated the form-upload handoff. At the end, he narrated successful population from the form entry. Proactive failure notifications and some edge cases were still deferred.
Accountants were asked to submit earlier creator reports to fill historical gaps. That backfill could support period comparisons, but a complete or reconciled reporting history was not demonstrated.
Inside the system / 03
Separate reporting preparation from financial assurance
The dashboards demonstrated summaries, sales and expenses sourced from the restructured sheet. The instructional example used test data, and historical backfill was requested as a next step. A working data-transfer demonstration does not establish audited accounting, complete transaction coverage or adoption across every creator.
Separate discovery material examined existing creator statements and sketched file intake, spreadsheet-row processing and document preparation. Those samples helped define requirements. Monthly automated statement distribution and a creator portal were proposed directions, not completed outputs shown by the reviewed evidence. The delivered component described here is the upload-to-reporting-data handoff.
Within INVIZ.tv