QuickBooks Online Advanced Script Developer

QuickBooks Online API Developer — Line-Item Job Costing Export to Excel Project Summary (Read This First) We are a high-volume audiovisual production company on QuickBooks Online Advanced. We need an experienced developer to build a script/connector that pulls line-item-level transaction data from the QuickBooks Online API and outputs a clean, formatted "Profit & Loss by Job" report to Excel. This replicates a report we relied on in QuickBooks Desktop Enterprise before migrating to QuickBooks Online, which we have been unable to reproduce in the online product. This report only needs to be run monthly — this is not a real-time or daily-automation project. A batch script we can run once a month (or on demand) for a chosen date range is exactly what we want. We have already diagnosed the technical problem thoroughly. We are not looking for someone to figure out whether this is possible or why the standard reports fail — we know both. We are looking for a developer who has genuinely worked with the QuickBooks Online API at the transaction/line-item level and can confirm the approach and execute it cleanly. If you read the "Core Technical Problem" section below and immediately recognize the distinction between line-item API data and the standard report endpoints, you are likely the right person for this job. Who We Are We run an audiovisual/audio production business that produces roughly 3,000 discrete projects per year, primarily audiobook and audio production work for major publishing clients. Each project ("job") has its own income and its own costs, and understanding true per-project profitability is central to how we price our work and manage the business. Our labor model is a mix of W-2 employees and 1099 subcontractors. Unusually, both our W-2 staff and our 1099 contractors fill out timesheets and bill their hours to specific projects, and in our bookkeeping both come through as Bills in QuickBooks. This detail matters for the logic described later, so please read the business rules carefully. We are on QuickBooks Online Advanced. We also use QuickBooks payroll, but for the purposes of this report, the labor data we care about flows through Bills, not paychecks. Background: The Report We Lost We previously ran our books on QuickBooks Desktop Enterprise, which included an excellent native "Profit & Loss by Job" report. That report gave us every income item and every expense posted against every individual job, in a single view. It let us see exactly what each job cost us, compare that to what we charged, and price future work accurately. It was, frankly, one of the main reasons the Desktop product worked well for us. When we migrated to QuickBooks Online Advanced, we lost the ability to produce this report, and we have not been able to replicate it using any of the built-in tools. We have spent significant time working through the available options — the standard Profit & Loss by Customer report, the Project Profitability report, Estimates vs. Actuals, and the Custom Report Builder available in QBO Advanced — and each one breaks down for our use case, for reasons detailed below. The Core Technical Problem (Please Read Carefully) This is the heart of the project, and understanding it is how we will separate qualified applicants from unqualified ones. QuickBooks Online's built-in reporting tools cannot cleanly export per-project cost data at our volume. There are several failure modes we've encountered, but the most serious and disqualifying one is this: When a single Bill contains line items tagged to multiple different projects, QuickBooks Online's reporting layer repeats the full bill total against every project, instead of showing each line item's individual amount against its own project. Here is a concrete example. One of our subcontractors submits a single bill covering work they did across several of our jobs in a pay period: 1 hour of work tagged to Project A — say $100 2 hours tagged to Project B — say $200 1 hour tagged to Project C — say $100 In QuickBooks, this is entered correctly: it is one Bill with three separate line items, each line carrying its own dollar amount and its own Customer/Project assignment. The underlying data is correct at the point of entry. We have verified this repeatedly by opening the actual bills. However, when we try to export this through the Custom Report Builder, the report shows the full bill total (or a header-level figure) repeated against each project, rather than the correct $100 / $200 / $100 split. In our testing we saw single bills tagged to dozens of different projects — in one case, a bill spread across more than 70 projects — where every project showed the same repeated amount instead of its true share. Across thousands of bills structured this way, any project-level cost total we try to build from these reports is wildly inaccurate. It systematically overstates costs on shared bills and makes the entire report untrustworthy. We also confirmed related limitations along the way: The Custom Report Builder reads certain data at the transaction/header level, not the line level. When we added a Project column, expense rows frequently came back blank even though the underlying transactions were correctly tagged, because the report was reading a header-level field rather than the per-line project tags. When we managed to surface line-level data, we then hit the multi-project repetition problem above, plus duplicate rows representing both sides of the double-entry bookkeeping (the expense line and its offsetting Accounts Payable line), which further muddied the export. The Project Profitability report calculates the per-project split correctly — inside an individual project's page, QuickBooks does show only the amount actually tagged to that project, not the full bill. But there is no way to bulk-export Project Profitability across all projects at once. Intuit's own support has confirmed you must open each project one at a time and export individually. At 3,000 projects a year, that is not remotely feasible. So we are stuck: the correct per-line data exists in QuickBooks, and QuickBooks even calculates the right per-project number internally, but there is no built-in way to extract it in bulk in a clean, line-item-accurate form. This is a well-documented limitation that many QuickBooks Online users have run into; it is not a mistake in our bookkeeping. Why the QuickBooks Online API Solves This Our understanding — which we want the selected developer to confirm and then build against — is that the QuickBooks Online API reads at the line-item level and therefore does not suffer from this problem. When you retrieve a Bill, Invoice, or Expense object through the API, it returns the transaction along with its full Line array. Each element of that Line array is a separate line object carrying its own Amount and, within its detail, its own Customer/Project reference (the per-line CustomerRef). This means a bill split across multiple projects comes back as multiple clean, separate line records, each already correctly attributed to the right project — exactly the data the report builder flattens and repeats. In other words: the API exposes the raw, correct, per-line data directly, bypassing the reporting layer that mangles it. This is the entire technical premise of the project. A developer who has done this before will recognize this immediately and be able to describe how the API represents a multi-project bill without hesitation. Refresh Frequency and Volume (Important for Scoping) Please note, because it affects how you build this and how you should bid: This report only needs to run monthly. It is not a live dashboard, not a real-time sync, and not a daily automation. We are perfectly happy with a script we run manually once a month, or on demand, for a chosen date range. You do not need to build scheduling, a hosted always-on service, incremental syncing, or webhook handling unless you believe it genuinely simplifies things. Because runs are infrequent, API rate limits are a non-issue for us. You can pull a full date range in a single monthly batch. You do not need to engineer around high-frequency request throttling. That said, the volume per run is substantial. A single month can involve a large number of transactions across hundreds of active projects, and a full-year pull would be several thousand transactions with many thousands of individual line items. Your script must page through the API results correctly to capture the complete dataset — partial pulls that silently truncate are exactly the kind of failure we need to avoid. The upshot: this is a well-contained batch-extraction-and-formatting job, not an ongoing integration engineering project. We think that keeps it modest in scope, and we'd rather pay for a clean, correct, well-documented one-time build than an over-engineered service. Detailed Scope of Work Phase 1 — QuickBooks Online API Access (OAuth 2.0) Set up API access against our live Production QuickBooks Online company file. We will create the app in the Intuit Developer portal and authorize access, or do so alongside you. You should be comfortable: Guiding us through creating the app and selecting the correct (Accounting) scope, if needed. Handling the OAuth 2.0 authorization flow correctly, including obtaining and using both the access token and the refresh token. Building token handling so that the monthly run does not require us to manually re-authorize from scratch every time — the refresh token flow should keep it working across runs with minimal friction. Clearly documenting where the credentials live and how to rotate or re-authorize them if they ever expire, so we are not dependent on you to keep it running. Phase 2 — Line-Level Data Extraction Build a script that queries all Bills, Invoices, and Expenses for a specified date range (we will pass in the start and end dates for each monthly run). The script must: Page through all results so the full dataset is captured, no silent truncation. Flatten every transaction to one row per line item, preserving line-level detail. Capture, for each line-item row, at minimum: transaction date, transaction type (Bill / Invoice / Expense), customer name, project name, account or category, and amount. Correctly handle the double-entry structure so that we get the real income/expense line, not the offsetting Accounts Payable / Accounts Receivable / bank / credit-card control lines. (We only want the lines that would appear on a Profit & Loss statement — income, cost of goods sold, and expense lines. We do not want the balance-sheet side of each entry.) Phase 3 — Business Logic Apply our specific business rules in code. These are described in exhaustive detail in the "Business Rules" section below. In summary: Consolidate labor into single task-category lines regardless of whether the worker is W-2 or 1099. Split out narrator/talent fees as separate pass-through income and expense lines. Exclude line items that have no project assigned. Exclude projects that have expenses but no income yet. Phase 4 — Formatted Excel Output Generate the final output as a single, formatted Excel worksheet matching a layout we will provide. The detailed layout specification is in the "Output Format Specification" section below. The output must be clean and immediately usable by non-technical finance staff — not a raw data dump. Formatting, grouping, headers, and the paired dollar/percent columns all matter. Phase 5 — Documentation and Handoff Deliver the complete working code along with clear, concise documentation, so that we can re-run the report ourselves for any future date range without needing to rebuild anything or come back to you. We want to own and operate this going forward. Documentation should cover: how to run it, how to change the date range, where credentials are stored and how to refresh them, and a brief explanation of how the business rules are implemented (so a future developer could adjust them if our accounting changes). Business Rules (Exhaustive Detail) These rules encode how our business actually works. Getting them right is most of the value of this project. Please read them carefully; they are the source of most of the nuance. 1. Labor Consolidation (W-2 and 1099 Combined) We have an unusual labor setup. Both our W-2 employees and our 1099 subcontractors fill out timesheets and bill their hours to specific projects, and in our books both come through as Bills. For this report, we do not want labor separated by worker classification. We want all labor for a given project consolidated into a single task-category line, regardless of whether the person doing the work was an employee or a contractor. In other words, do not create separate "employee labor" and "contractor labor" columns or lines — combine them by the nature of the work/task category. If our chart of accounts distinguishes task categories (for example, different types of production labor), consolidate within each project so that labor reads as clean single lines per category, not fragmented by worker type. 2. Narrator / Talent Fee Pass-Through For some projects we charge narrator fees (we use the terms "narrator" and "talent" interchangeably). These fees are largely a pass-through: we pay the narrator, and we bill the client for the narrator's fee, with only a small markup (a few percent, which functions as a bookkeeping/handling fee). Because these are essentially pass-through amounts and not part of our core marked-up service revenue, they need to be broken out separately rather than blended into our main income and cost figures. Specifically: The narrator-fee income should appear as its own separate line, which we think of as "Income Other — Narrator Fees." The corresponding narrator-fee expense should appear as its own separate line, "Expense Other — Narrator Fees." In our books these are coded under accounts/labels we refer to as "Talent" or "TalentReimb" (talent reimbursement). Both should be treated as narrator-fee pass-through and mapped to these separate income/expense lines. The goal is that when we look at a project, we can clearly see our core service revenue and core costs separately from the narrator pass-through, because the pass-through distorts margins if it's blended in. 3. Exclude Line Items With No Project Any line item that has no project (Customer/Project) assigned should be excluded from this report. These are overhead and general/administrative expenses that are not attributable to a specific job — things like office costs, general business credit-card expenses, and so on. We are deliberately ignoring overhead for this particular report. Do not attempt to allocate overhead across projects; simply drop any line with no project tag. 4. Exclude Projects With No Income Any project that has expenses but no income should be excluded from the output. In our workflow, a project with costs but zero income simply hasn't been invoiced yet — the income is coming, it just hasn't been booked. We don't want to analyze the profitability of half-complete, not-yet-invoiced jobs in this report, because they would show as artificially unprofitable. So: if a project has no income line at all in the date range, leave it out entirely. Output Format Specification (Exhaustive Detail) We will provide a sample spreadsheet showing the exact target layout, plus an example of the older QuickBooks Desktop report we are trying to replicate, so you can match it closely. Here is the specification in words: Overall Structure A single Excel worksheet (one tab) containing the whole report. Each individual project is its own column. Projects run horizontally across the sheet. Row 1 contains the customer name. Row 2 contains the project name. So reading down the top of any project column tells you which customer and which project it is. Below those header rows, the rows are the income and expense line items (service revenue, the consolidated labor task categories, narrator-fee pass-through income and expense, other costs, and the resulting profit/margin), laid out like a profit-and-loss statement running vertically. We will provide the exact line-item order and labels via the sample; where we don't have data for a given standard line, it's fine to show zero rather than omit the row. Grouping and Sorting All projects belonging to the same customer are grouped together, placed in adjacent columns. Customers are sorted alphabetically. So the leftmost group of columns is the alphabetically-first customer's projects, and so on across the sheet. The "Indie Author" Consolidation Any customer that has fewer than two projects (i.e., a customer with only a single project) should be grouped together under a combined heading we call "Indie Author" (short for Independent Author). Rather than giving each one-off single-project customer its own tiny group, all of these single-project customers are collected together under the "Indie Author" customer name in Row 1. This keeps the report readable by consolidating the long tail of one-off independent authors into a single logical group. Per-Customer Total Column At the end of each customer's group of project columns, add a total column that sums that customer across all their projects. For example, if a customer has five projects occupying five columns, the sixth column is that customer's total across those five projects. Every customer group gets its own trailing total column. The Dollar / Percent-of-Revenue Column Pairs For each project column, there is a paired column immediately to its right showing each line item as a percent of that project's revenue. So the primary project column holds the actual dollar values, and the column right next to it expresses those same line items as a percentage of the project's revenue. This lets us read both the absolute dollars and the margin structure side by side for every job. A note on what "revenue" means for the percentage calculation: our core revenue is the amount we charge for our services. Narrator fees, as described above, are pass-through and are booked separately as "Income Other — Narrator Fees." When we discuss the sample with the selected developer we will confirm precisely which figure the percent-of-revenue should be calculated against, but the key point is that the pass-through narrator income should be handled distinctly from core service revenue in these calculations. Technical Approach and Stack We are open to Python or Google Apps Script, whichever you believe is the more robust and maintainable choice for a monthly batch job that a non-developer can run. We'd like to hear your reasoning briefly in your proposal. The Excel output quality matters. It should be clean, well-formatted, and immediately usable by non-technical finance staff. Proper headers, number formatting, grouping, and the paired dollar/percent columns should all render cleanly. Because this runs monthly and we want to own it, simplicity and maintainability beat cleverness. A clear, well-commented script we can understand and adjust is worth more to us than a highly abstracted framework. Deliverables Checklist Working code that authenticates to our QuickBooks Online Production account via OAuth 2.0 and reliably refreshes its token for repeat monthly runs. Extraction logic that pulls all Bills, Invoices, and Expenses for a supplied date range, paged fully, flattened to one row per line item with the correct fields, and correctly excluding balance-sheet offset lines. Business-rule logic implementing labor consolidation, narrator-fee pass-through separation, exclusion of no-project lines, and exclusion of no-income projects. A single formatted Excel worksheet matching the provided layout (projects as columns, customer in row 1 / project in row 2, alphabetical customer grouping, Indie Author consolidation, per-customer total columns, and dollar/percent-of-revenue column pairs). Documentation covering how to run it, how to change the date range, credential storage and refresh, and how the business rules are implemented. A short walkthrough (call or written) so our team can run it confidently on our own. Milestones and Budget We strongly prefer a fixed-price contract structured in milestones, rather than hourly. Suggested structure: Milestone 1 — Proof of correct line-level extraction (≈30%): You connect to our live account and demonstrate a clean pull that correctly splits a known multi-project bill into its individual per-project line amounts. This proves the core technical premise works against our actual data before we go further. Milestone 2 — Finished formatted report (≈70%): The complete script with all business rules applied and the formatted Excel output matching our layout, plus documentation and handoff. Please propose your own fixed price against this scope in your application, and feel free to suggest a different milestone split if you think it structures the risk better. We're interested both in the number and in how you justify it — a bid that references the actual technical work involved tells us more than a bare figure. Timeline This is not urgent to the day, but we would like it built within a few weeks of hiring. Because the report runs only monthly, there's no live-system pressure — we care much more about correctness than speed. Please include your estimated timeline in your proposal. Required Experience Demonstrable prior experience with the QuickBooks Online API (Accounting scope), specifically pulling transaction and line-item-level data — not just calling the standard pre-built report endpoints. This is the single most important qualification. Fluency with the OAuth 2.0 authorization and token-refresh flow for QuickBooks Online. Strong Python or Google Apps Script skills. Clean Excel generation, including formatting, grouping, and formulas/percentages. Care and precision with financial data — this feeds real pricing and profitability decisions, so correctness is paramount. Nice to Have Prior work replicating QuickBooks Desktop job-costing/P&L-by-Job reporting in QuickBooks Online specifically. Experience with production, media, agency, or other project-based businesses where per-job costing matters. Familiarity with pass-through / reimbursable billing structures. How to Apply — Screening Questions Please answer these briefly in your proposal. They help us quickly identify who has genuinely done this before: Have you pulled line-item-level Customer/Project tags from the QuickBooks Online API before? Please describe how the API represents a single Bill that is split across multiple projects. (This is our key technical screen — a specific, confident answer here matters most.) Roughly how long do you estimate this project taking, and would you build it in Python or Google Apps Script, and why? Please share one relevant past project involving the QuickBooks API, ideally one involving transaction/line-level data. What is your proposed fixed price for this scope, and how would you structure the milestones? A Final Note on Fit We have already done the diagnostic work and understand our own problem precisely. We know the line-item data exists, we know why the built-in reports fail, and we know the API is the path to the clean data. We are not looking for someone to explore whether this is possible — we're looking for an experienced developer who can confirm the approach, execute it cleanly, correctly handle the specific business logic around multi-project bill splitting and pass-through narrator fees, and hand us a reliable, repeatable, well-documented tool that we own and run monthly ourselves. If the line-item-versus-report-endpoint distinction is second nature to you, we'd love to hear from you.