Sponsorships in projects

Open a project in Transactions → Projects, then Sponsorships. Reuse its existing customer record for the legal sponsor. An individual payer can be a different person. A sponsorship adds context and source associations; it never creates a second ledger or changes a bank receipt's tax, category, review status or reconciliation.

Start with an existing receipt

Open an income transaction's Sponsorships section and choose its project. Review evidence proposal reads already preserved Notes and cached receipt or screened email readings. It starts no inbox connection or model job. Check the exact quotes, unknowns and existing customer candidates. Keep proposed context creates proposed metadata and a reference to this receipt only. It leaves Notes and financial fields unchanged. Choose the actual customer after inspecting the source; matching a payer's name or amount alone does not establish identity.

Use Save Notes only to add factual Notes while keeping the transaction's review status. Mark reviewed remains a separate action. Existing Notes are never automatically rewritten as structured facts.

Historical original invoices belong in the existing transaction's Evidence tab. Supporting uploads read and preserve the original without reissuing it, sending it or creating another transaction. Their progress shows preservation, page preparation and printed-fact reading. A source invoice's currency, tax and payment assertions remain distinct from booked amounts and reconciled payment evidence. A due date alone does not mean unpaid. An unavailable printed invoice number, issue date or tax stays unknown.

Record the agreement and benefits

Add the sponsor to the project, select an optional reusable package and enter the promised benefits and performance dates. Keep agreement close, receipt, performance, revenue-recognition and tax-point dates separate. Country and residency facts can cite preserved originals or exact saved Notes. Customer country alone never decides GST/HST.

Proposed treatment, administrator confirmation and accountant approval are separate stages. Confirmation binds to current record and source revisions. A changed source pauses approval until it is reviewed again. The existing accountant correction permission is required for accountant approval; this feature grants no access to originals, mail or other companies.

What is still needed names the concrete gap, responsible person and useful evidence to provide. Resolved gaps disappear. These prompts stay in the app and send no email.

Draft a sponsorship invoice

From a project's sponsor or the customer's linked sponsorship, choose Draft sponsorship invoice. Reusable packages support hackathons, retreats, events and other sponsored initiatives through the existing invoice template engine. Check the legal billing identity, currency, price, package and benefits, performance dates, terms and explicit tax choice in the preview.

Unknown tax stays unreviewed, even when the draft stores zero tax. It blocks issue/send until the existing invoice workflow explicitly reviews the tax. Zero-rating is a recorded choice requiring evidence and review, never a conclusion inferred from country or zero. Saving a draft does not issue its permanent number or send it. Existing invoice reviews, duplicate controls, issue/send approvals, partial payments and payment reversals still apply.

Keep a historical original as supporting evidence instead of issuing a new invoice for an already captured sale. Cross-currency settlements need explicit provider or conversion evidence; equal converted amounts alone never confirm a match. Original invoice amounts and bank settlement gross, fees and net are different facts.

Link sources and report

Link existing receipts, invoices, refunds, fees and invoice payments with a reason. A blank association amount is a reference only. Partial allocations use the source currency and cannot exceed that source across sponsorships. Refresh a changed association only after inspecting its current source. Removing an association removes no financial record.

Project reports accept inclusive From/To dates, which can follow a fiscal year. They show allocated receipts, refunds and fees separately by currency. Issued invoices use a separate basis. Invoice payments are references and are never added to bank receipts as another revenue. Draft invoices, stale revisions, missing dates, reference-only associations, exclusions and incomplete coverage remain explicit. Reports do not infer or prorate tax. Saved all-tax, reviewed GST/HST and proposed sponsorship treatment remain separate.

Ask AI, MCP and terminal

All surfaces use the same permission-checked sponsorships.* actions. Discover them in the invoicing MCP toolset. Read sponsorships.get before editing or confirming, and sponsorships.report for the project's currency-separated evidence. Page through lists using their returned coverage and next offset.

For enrichment use sponsorships.context.propose, then sponsorships.context.review. Show its exact proposal and obtain human confirmation before sponsorships.context.accept with the unchanged fingerprint and proposal revision. This action accepts only context proposals, never category, payment or other financial proposals. sponsorships.review similarly binds administrator/accountant confirmation to the current source fingerprint. Ask AI shows these native reviews and pauses approval while loading, failed, incomplete, stale or in another company.

For invoices call sponsorships.invoice.preview, inspect the calculation, then sponsorships.invoice.createDraft with the unchanged preview hash and choices. Continue with the existing invoice actions for issuing, sending or recording a payment. The terminal has native sponsorship, package, evidence proposal, invoice preview, review and project-report flows; headless commands and its MCP bridge expose the same schemas. Every write uses current revisions, idempotency and History.