Transforming a manual, multi-sided billing process into a scalable enterprise solution

Workflow design, problem definition, rapid iteration || Reduced manual effort by 80%

Sydecar is on a mission to standardize, automate, and disrupt tedious processes like compliance, banking, and reporting to build a scalable solution that simplifies private investing. It is a multi-sided platform used by deal leads, investors, and internal operations managers. Deal leads use Sydecar’s Fund+ product to manage their investments, paying quarterly fees based on their fund’s committed capital.

Role
Senior Product designer

Collaborators
Senior Product manager, 2 Engineers

Stakeholders
Finance team, Deal operations team

Q3
2025

What we know

As with many start-ups, little was known when the project started:

  • Deal leads often do not know how much they owe because invoices are not shown anywhere in product and they don’t have a way of estimating fees
  • The current process was error-prone and confusing, burning the time of deal operations associates. When things went wrong, a lot of time and energy was wasted trying to pinpoint the source of the problem leading to a deterioration in the trust between the two teams
  • All the billing and invoice data lives elsewhere and bringing it in product will reduce dependencies on external products and gives us a more complete picture about the fund’s finances for financial reporting purposes

What we need to learn

The current flow – The current flow was not well documented, the user problems were largely anecdotal, not properly articulated or quantified

The math and fee structure – The formula for calculating fees was unclear, we needed to verify the pricing model and calculation logic to bring into product.

Scope and integration – Do Deal leads want to pay invoices online? How far should this solution extend?

Information flow – How does billing information flow into Sydecar’s financial and accounting systems?

Customer behavior – How do Deal leads estimate their fees and plan to pay them?

Shadowing Dylan on the deal operations team

I spent a few days with Dylan as he was processing invoices

  • Quarterly billing was a 10-step entirely manual process. The process was slow, error-prone, and pulled the deal operations team away from higher-priority work.
  • At the end of every quarter, a deal operations associate had to copy data from Sigma and paste in into an excel template to calculate fees. Then export it as a pdf and send it to customers.
  • Then, they raise an Asana ticket for the finance team to create the invoice in QuickBooks. Payments were recorded in QuickBooks, but there was no connection between the invoice and payment systems.

Fig 1: Current error-prone flow with many external dependencies

Articulating the problems for all users

User stories

As a deal operations associate, I want to automate invoice generation and delivery so that I can focus on higher-priority work instead of spending hours copying data between systems.

As a finance team member, I want billing data automatically synced to QuickBooks so that I can trust our records and see payment status without manual reconciliation.

As a fund manager, I want all my invoices in one place in Sydecar so I never miss payment and can keep track of how much is owed.

Starting scrappy to test assumptions fast

I made many assumptions and identified a solution

  • Create a way for deal operations to generate an invoice every quarter and send a PDF via email
  • Build a calculator widget to help Deal leads estimate their bill
  • Build an invoicing center to help Deal leads manage payments
  • Connect the billing engine to the QuickBooks API to make sure invoices show up in the internal accounting system

The best way to prototype financial software is with spreadsheets. I created a very scrappy flow and a working spreadsheet model of the billing math to illustrate the calculator widget.

Fig 2: First pass at the end to end flow

Pivoting to the right problems for the right users

Through early testing with finance and deal operations teams, I learned:

  • The main user is the finance team, not deal operations – This automation would allow finance to own the process end-to-end, removing deal operations from the workflow entirely, and reducing the amount of possible errors and eliminating the need for a handoff
  • Fund managers don’t need another calculator – The Sales team already had a spreadsheet that worked well, Fund Managers get the spreadsheet from their account managers and don’t need a in-product solution
  • No one pays online – Most customers either send wire transfers or mark it as a fund expense to be debited from their account balance. Online payment wasn’t a priority.

Fig 3: Streamlined flow with minimal dependencies

Finding the most impactful solution

As I refined the designs with finance:

  • No “create invoice” button needed – The billing engine automatically outputs an invoice every quarter. The interface just needs to support adding and editing line items.
  • Status workflow – Because all invoices will be programmatically generated, the finance team needed an Approval flow.
  • Invoice email – Invoices needed to be sent via SendGrid, the company’s internal email tool, and not manually by team members
  • New invoice PDF template – The current invoice PDF was a default template from SendGrid, signaling very low trust, I wanted to use this as an opportunity to change that

Fig 4: Initial wireframes for invoices and create invoice flows

Fig 5: Initial lo-fi designs for invoices and create invoice flows

Balancing nuance and scale

Final refinements came from testing with real data:

  • Support for discounts – Discounts are common line item, the add item flow had to flex to negative numbers
  • Memo field – Customers often asked for a specific name or information to be included in the invoice and the finance team needs a memo field
  • No due date – Invoices are due on receipt, so showing a due date in the Invoices tab was unnecessary and confusing since they would just default to a late status

Fig 6: View and approve invoice details

Fig 7: Edit invoice details

Fig 8: Fund manager Invoice center and pdf

The end to end quarterly billing solution included:

  • Automated invoice generation from the billing engine with editing capabilities and approval workflow for finance team
  • Support for multiple billing types (quarterly fees, LLC fees, pass-through expenses)
  • SendGrid integration for automated email delivery with a crisp new professional PDF invoices
  • Connecting to the QuickBooks API to make sure information flowed back and forth easily

Results

The new system reduced manual effort by 80%, transforming a multi-day process into a few minutes of review and approval. Instead of taking several people in deal operations, the new flow empowers one team member in finance to manage the entire billing process.

Deal leads receive consistent invoices that are easy to understand, signal trust and they never miss a payment.

The engineering team built integration between QuickBooks and the invoice system, allowing payment data to automatically sync and update invoice statuses when customers pay.

Takeaways

Designing for automation means that the flow changes, a lot – The initial solution was designed for the deal operations team, since they own this process. But as I continued to iterate we identified this flow can be taken off their plate and owned by finance entirely.

Finding the perfect fidelity for prototypes – When working with broad stakeholders, placeholder math in Figma would always end up being a distraction. So I started using spreadsheets to prototype products and demonstrate customer value with the lowest effort.

Edge cases define quality in financial tools – Discounts, memo fields, and copy writing – these details matter enormously in finance. It’s important for designs to be scalable to all edge cases and to have a good attitude as requirements will still be coming out at the end.

Dikssha Dinesh 2026 | Built with love on WordPress