QuickBooks is the accounting authority. Knack is the operational authority for eligibility, invoice workflow, documents, credits, exam linkage, and downstream status.
Executive summary
At a glance
Auditor-paid single invoices, firm-paid aggregate invoices, and firm credit redemption. A “credit invoice” is an APSCA prepayment bucket, not clearly a QuickBooks CreditMemo.
QuickBooks invoices carry credit-card and bank-transfer instructions. QuickBooks records the payment; webhooks and reconciliation jobs copy paid state back.
Rules are split across Knack views/formulas, browser code, server code, QBO, and scheduled jobs. Client-visible restrictions are not enough as server authorization.
Most important modeling conclusion
The current Knack “Invoice” object combines at least four concepts: a charge request, a QuickBooks invoice projection, an auditor entitlement/work item, and a reusable firm credit account. The replacement should separate those concepts while keeping QuickBooks as the accounting ledger.
Section 1
Current State
The present design is an integration rather than a single invoice service. Knack creates and stores operational records. The Express server translates them to QuickBooks, stores generated PDFs back in Knack, and later mirrors payment state from QuickBooks.
1.1 System responsibilities
| System | What it owns today | What it does not reliably own |
|---|---|---|
| Knack | Invoice/workflow records, invoice types and prices, payer choice, audit-firm connections, eligibility counts/formulas, credit balances, documents, exam status, change requests, and UI access. | The authoritative accounting balance or payment transaction. |
| apsca_knack browser code | Eligibility checks, form orchestration, payer/payment-method selection, batch cart building, credit validation prompts, and calls to the APSCA server. | Trusted authorization. The browser sends IDs, prices, QBO references, audit-firm IDs, and user IDs that the server often accepts. |
| apsca-server | QuickBooks OAuth/API access, customer lookup/creation, invoice creation/email/PDF retrieval, Knack record updates, batch and credit orchestration, webhooks, reconciliation, and downstream cron work. | A durable transactional financial database. Multi-record operations are spread across external calls. |
| QuickBooks Online | Accounting customer, issued invoice, document number, line items, invoice balance, and recorded payments. | Auditor eligibility, exam fulfillment, membership status, or the internal APSCA credit-allocation ledger. |
“Created” has two meanings
A Knack invoice record may exist before a QuickBooks invoice exists. For a normal single invoice, the server later creates the QBO invoice and writes back the QBO document number, status, date, and PDF. For firm credit redemption, a new child record can be fulfilled from an existing credit invoice without creating a new QBO invoice at all.
1.2 Core current-state record model
Invoice Type
Knack configuration holds the business type, cost, and production/development QBO item and class references. Exam variants are also hard-coded by Knack record ID in client/server maps.
priceQBO itemQBO classexam variant
Invoice (overloaded)
One object stores payer, auditor, firm, type, amount, QBO number/status, date paid, files, scheduling data, subtype, parent links, credit totals, and operational status.
singlemasterchildcredit
Supporting records
Change requests, credit transactions, and credit changelog records track adjustments around the invoice object. Audit firms and auditors carry calculated counters and QBO customer references.
change requesttransactionchangelog
Primary evidence: controllers/Knack/knack_object_map.js:20-91, types/batchExamInvoices.ts:1-84, and the Knack mapping in src/controllers/knack_obj_map.ts.
1.3 Who can create an invoice, and when?
| Path | Initiator / payer | Creation conditions visible in code | Accounting result |
|---|---|---|---|
| Auditor self-service exam | Auditor initiates and is instructed to use this path only when the auditor will pay. | Auditor must be In Good Standing; have an eligible exam flag; have no unpaid or pending exam invoices; have no unpaid Part 3 fee invoices; and, for Part 3, have an approved audit log. The chosen language/method selects the invoice type. | Knack record is created, then the client immediately asks the server to create and email a QBO invoice. |
| Auditor self-service membership | Auditor initiates and pays their own membership fee. | Self-service is disabled during January so the firm can decide whether it will cover the fee. Current messaging opens it 1 February with a 15 February target. A duplicate year invoice is blocked using year-specific calculated count fields. Separate normal/inactive forms and types exist. | Knack record is created, then QBO invoice generation runs and the invoice is emailed to the auditor. |
| Firm batch exam fees | A logged-in account connected to an audit firm initiates; the audit firm pays. | The account needs an audit-firm connection, the firm needs a QBO customer ID, no firm batch may already be flagged in progress, and each auditor must pass firm-side eligibility. Firm-specific exemption logic can relax which prior unpaid invoices disqualify an auditor. | One aggregate QBO invoice is created. Knack receives one Master record and one Child record per auditor/line. |
| Firm batch membership fees | A logged-in firm account initiates; the audit firm pays. | The user selects an active membership year. Auditors connected to the firm are offered only when the year-specific invoice count is zero. Inactive auditors can receive a discounted invoice type. | One aggregate QBO invoice plus Master and Child Knack records. |
| Admin/manual single invoice | APSCA staff selects Auditor or Audit Firm as payer. | A Knack invoice record must exist, Paid By must be Auditor or Audit Firm, no QBO invoice number may already exist, and No Charge must not be Yes before the “Generate QB Invoice” button is enabled. | One QBO invoice. Bill-to customer and email recipient are chosen from Paid By. |
| Credit redemption | Firm pays from a matching active credit invoice. | Only Audit Firm payees may select credit. Credit must be the matching exam/membership subtype, not flagged in use, and have enough balance. Single and batch variations exist. | No new QBO invoice. A Child record reuses the parent credit invoice number and consumes internal credit. |
| Exam cancellation/reschedule fee | Auditor or firm, based on the request and original invoice. | Part 3 fees can be generated after the free-reschedule limit or for action within the configured 2–30 day window. If charged to the auditor, QBO generation is automatic. If charged to a firm, the code creates the Knack record and emails Accounts for manual handling. | Automatic QBO invoice for auditor-paid fees; potentially manual QBO work for firm-paid fees. |
Evidence: apsca_knack/src/helpers/auditorGenExamInvoice/helpers/determineExamEligibility.ts:155-205, .../showFormDescription.ts:11, .../auditorGenMembershipInvoice/helpers/disableForJanuary.ts:11-33, .../initInvoiceTypeChangeHandler.ts:36-63, .../batchExamInvoicesApp/App.vue:129-172, .../sanitizeAndFilterAuditors.ts:106-161, .../generateSingleInvoice/index.ts:36-47, and controllers/proctor-u/services/invoiceFeeService.ts:11-148.
Authorization gap
The server middleware verifies that a supplied Knack token represents a valid user, but it does not itself enforce invoice role, firm ownership, or resource scope. Several routes accept firm ID, user ID, invoice IDs, price, and QBO mapping data from the browser. Today, Knack scene/view permissions and UI filtering carry more security responsibility than they should.
middleware/authenticateUser.js:3-42, middleware/validation/invoiceRoutes/batchInvoicing.ts:1-13, types/batchExamInvoices.ts:17-28.
1.4 Who pays?
Auditor-paid
- The auditor is the QBO Customer. The server searches QBO by the auditor email; if none exists, it creates a customer using auditor name, email, membership number, and firm.
- The QBO invoice is emailed to the auditor. A PDF is stored in the auditor-visible Knack file field.
- Self-service exam copy explicitly warns auditors not to use the path when their firm will pay.
Audit-firm-paid
- The firm’s stored QBO customer ID is used; it must already refer to a valid QBO Customer.
- A normal single invoice is emailed to the audit-firm billing email. A batch invoice is emailed to the logged-in firm user who requested it.
- Batch child records identify the individual auditors, but the firm owes the single aggregate QBO invoice.
“Paid By” currently mixes party and workflow
Values such as Auditor, Audit Firm, and To Be Invoiced are used as both billing-party decisions and workflow states. No Charge is separate. The future model should use a typed bill-to party plus separate lifecycle/status fields.
Evidence: controllers/mainRoutes/helpers/getOrCreateQBCustomer.ts:12-110, controllers/mainRoutes/generateQBInvoiceFromKnack.ts:181-231, controllers/generateBatchInvoices/helpers/createMasterInvoice.ts:43-54, and controllers/generateBatchInvoices/helpers/emailInvoiceToUser.ts:16-53.
1.5 How normal invoices are issued
1
Request
Knack form or firm cart creates/assembles an operational invoice request.
2
Resolve
Server reads Knack invoice type, QBO item/class, price, payer, and QBO customer.
3
Issue
Server creates the QBO invoice with one or many sales-item lines.
4
Deliver
QBO emails it. Server downloads the QBO PDF and uploads it to Knack.
5
Project
Knack gets QBO number, Created status, invoice date, PDF, and master/child links.
For a single invoice, each QBO line amount is read from the QBO Item’s UnitPrice, not the Knack invoice amount. For batch requests, the client includes price and QBO mapping data, but the QBO line amount is again derived from the fetched QBO item. The Knack child amount is written from the client payload’s price, so the operational and accounting values can diverge.
Every QBO invoice receives standard APSCA memo text directing payment by credit card through the APSCA member-payments page or by bank transfer; checks are not accepted. The application itself does not capture card details.
Evidence: controllers/mainRoutes/generateQBInvoiceFromKnack.ts:91-257, controllers/generateBatchInvoices/index.ts:58-129, controllers/generateBatchInvoices/helpers/generateLineItems.ts:21-77, controllers/generateBatchInvoices/helpers/createChildInvoices.ts:69-105, and controllers/quickbooks/helpers/invoiceConstants.ts:5-16.
1.6 Master, Child, and Credit semantics
| Subtype | Meaning | QuickBooks relationship | Paid behavior |
|---|---|---|---|
| Single / Auditor | One auditor’s membership, exam, or fee obligation. | Usually one QBO invoice. | Payment sync updates the same record. |
| Exam Fee Master / Membership Fee Master | Firm-level operational representation of an aggregate batch. | One QBO invoice with one line per auditor. | Master becomes paid from QBO; children inherit payment. |
| Child | Per-auditor allocation/entitlement below a firm Master or Credit. | Not a separate QBO invoice. It shares the parent document number. | Paid state comes from the parent master/credit. |
| Exam Fee Credit / Membership Fee Credit | A firm prepayment bucket with amount, used, balance, adjustments, active status, and audit log. | Backed by an existing paid QBO invoice; it is not modeled as a QBO CreditMemo in this code. | Redemptions consume internal balance and create paid Child records if the credit parent has a paid date. |
Credit operations are not transaction-safe
The workflow reads a balance, creates children, then writes a new used total. A Knack boolean marks a credit invoice “in use,” but that is advisory and not a database lock. Partial failures or concurrent writers can leave child allocations and credit totals out of agreement.
controllers/generateBatchInvoicesCredit/index.ts:17-160, controllers/generateBatchInvoicesCredit/helpers/getCreditInvoiceData.ts:21-61, controllers/invoices/redeemCreditInvoice.ts:53-151.
1.7 How invoices get paid and synchronized
1
Customer pays
Payment occurs outside the custom application using the invoice instructions / QBO-supported payment process.
2
QBO records it
QuickBooks holds the Payment and reduces Invoice Balance.
3
Webhook
A signed Payment Create webhook causes the server to fetch Payment and linked Invoice.
4
Confirm
The server treats QBO Invoice Balance = 0 as paid.
5
Project & fulfill
Date Paid / Paid are written to Knack; children and downstream workflows follow.
There are two synchronization mechanisms:
- Webhook fast path. A QuickBooks Payment creation webhook is signature-validated, then processed asynchronously. The server reads each linked QBO Invoice and updates matching unpaid Knack records when QBO Balance is zero.
- Scheduled reconciliation safety net. A batch job queries Knack records with a QBO number and no paid date (excluding Child records), queries QBO invoices/payments, and writes the QBO payment date and Paid status back. A separate job propagates a paid Master’s date/status to Child records.
Only fully paid is modeled
The operational model recognizes “Created” and “Paid.” Partial payment, overpayment, void, refund, failed payment, write-off, and disputed states are not first-class lifecycle states here, even though QuickBooks can represent richer accounting outcomes.
Evidence: routes/webhooks.ts:8-40, controllers/webhooks/processWebhook.ts:13-37, controllers/webhooks/handlePaymentCreationWebhook.ts:21-118, crons/markInvoicesPaid/batchedHandler.ts:73-208, and crons/updateChildInvoices/handler.ts:14-137.
1.8 What “fulfilled” means
Exam invoices
- Exam instructions are emailed after invoice generation or credit redemption—not strictly after payment.
- The codebase supports scheduled exams whose auditor-paid invoice is still unpaid, because reminder jobs target invoices with an exam date and blank paid date.
- Prior unpaid/pending exams usually block creation of another exam invoice. Firm exemption logic changes part of this rule.
- Cancellation/change approval may refund value into the firm’s newest active matching credit invoice; if no credit exists, Accounts must handle the refund manually in QBO.
Membership invoices
- Invoice raised/paid state feeds auditor year-specific calculated fields and annual checklist/lapse workflows.
- Auditors with a raised but unpaid membership invoice can be lapsed by scheduled processing.
- Restoration checks combine membership payment/firm-payment conditions with other annual requirements.
- The nominal
/update-employmentsroute currently responds successfully but performs no update, suggesting leftover orchestration baggage.
Evidence: crons/reminderEmails/helpers/constructFilterRules.ts:9-33, crons/lapseUnpaid2025MembershipAuditors/handler.ts:45-269, crons/auditor2025ChecklistStatusRestoration/handler.ts:39-71, and routes/invoices.ts:198-206.
1.9 Operational and architectural baggage
Knack coupling
- Opaque object/field/view/scene IDs throughout both repositories.
- Business rules split between invisible Knack formulas/view filters and TypeScript.
- Year-specific invoice types and auditor count fields require annual code changes.
- jQuery/Knack lifecycle events orchestrate financial work.
- The same PDF asset ID is copied into multiple audience-specific fields.
Integration coupling
- QBO OAuth tokens are persisted in a Knack object rather than an encrypted application secret store.
- Legacy and current QuickBooks routes coexist.
- QBO customer identity for auditors is matched by mutable email.
- Background work often returns HTTP 200 before it completes; durable job identity/state is limited.
- Webhook processing is fire-and-forget and payment event deduplication is not explicit.
Discovery boundary
This review covers both codebases, but Knack’s declarative schema, formulas, record rules, page permissions, view filters, and native automation are not fully represented in source control. Before cutover, export and inventory those Knack settings. Treat the code-derived rules in this report as the confirmed code layer, not the entire live-system contract.
Section 2
Future State
The new application should own the operational billing domain in a transactional database, keep QuickBooks as the accounting authority, and connect them through explicit asynchronous synchronization. Next.js should be the user-facing and API boundary; durable Node workers should handle QBO, email, PDFs, webhooks, and reconciliation.
2.1 Recommended boundary
1
Next.js UI
Shows server-derived eligibility and collects intent, never authoritative price or tenant scope.
2
Domain service
Authorizes actor, prices charge, snapshots payer, and commits request plus outbox event.
3
Worker
Idempotently creates/updates QBO, stores PDF, delivers email, and records results.
4
QuickBooks
Owns issued invoice, balance, payments, voids, and accounting customer.
5
Projection
Webhook/reconciliation updates local accounting projection and emits fulfillment events.
Keep QuickBooks; replace the orchestration around it
There is no benefit in rebuilding accounts receivable unless APSCA intends to replace QuickBooks. The app should own intent, eligibility, allocation, fulfillment, and auditability while QBO continues to own accounting issuance and payment truth.
2.2 Proposed domain model
BillingRequest
The user’s intent: exam, membership, reschedule/cancel fee, or prepayment. Contains actor, subject(s), requested payer, source, and idempotency key.
Charge
The immutable priced obligation. Stores currency, integer minor units, product/version snapshot, bill-to party, subject, reason, and effective year.
AccountingInvoice
Local projection of one QBO invoice: QBO ID, DocNumber, SyncToken, customer ID, total, balance, status, PDF/object key, timestamps, and last sync.
InvoiceAllocation
Connects one aggregate QBO line/invoice to individual Charges. Replaces fake “child invoices” while preserving per-auditor reporting and fulfillment.
PaymentProjection
Stores QBO Payment ID/date/amount and allocations. Supports partial and multiple payments without pretending Date Paid is the whole payment model.
CreditAccount + LedgerEntry
Append-only firm credit ledger, scoped by purpose/currency. Balance is derived transactionally from deposits, allocations, releases, refunds, and adjustments.
Fulfillment
Separate exam entitlement, membership-year requirement, or fee consequence. It references the Charge and has its own state and policy.
ChangeRequest
Structured requested change, approval, reason, actor, result, and financial adjustment. It should never directly mutate a balance without a ledger entry.
IntegrationEvent / Outbox
Durable work record for QBO issue, PDF fetch, email, payment sync, and fulfillment. Enables retries, observability, and idempotency.
2.3 Lifecycle: separate billing from fulfillment
| Concern | Recommended states | Why separate it |
|---|---|---|
| Billing request | Draft → Submitted → Accepted / Rejected → Processing / Failed | A request can fail before any QBO invoice exists. |
| Accounting invoice | Pending issue → Issued → Partially paid → Paid → Voided / Written off | Represents QBO truth without overloading business workflow. |
| Credit allocation | Reserved → Posted → Released / Reversed | Supports atomic reservations and recovery from failed fulfillment. |
| Fulfillment | Pending payment / Eligible → Ready → Scheduled / Satisfied → Cancelled | APSCA can explicitly decide whether each product is pay-before-use or pay-after-schedule. |
| Delivery | Queued → Sent → Failed | Email/PDF failure should not change whether the accounting invoice exists. |
Resolved policy: scheduling, payment, and exam progression
An auditor may schedule and take the current exam before its invoice is fully paid. The exam results must be withheld until full payment is confirmed. The auditor also cannot create the next exam’s invoice until the previous exam invoice has been paid. The replacement must model these as separate controls: scheduling is allowed, result release is payment-gated, and progression to the next exam invoice is payment-gated.
2.4 What baggage can be left behind
Remove outright
- Knack object, field, view, and scene IDs.
- jQuery/Knack event-driven financial orchestration.
- Year-specific code maps and “number of 20XX invoices” fields.
- Duplicate PDF audience fields pointing to the same asset.
- Legacy QBO endpoints and duplicate OAuth paths after cutover.
- The no-op employment-update endpoint.
- Browser-supplied prices, QBO item/class IDs, actor IDs, and firm scope.
- Boolean “batch in progress” and “credit in use” fields as locks.
Replace with a cleaner equivalent
- Master/Child invoice records → QBO invoice header + lines + internal allocations.
- Mutable credit totals → append-only credit ledger with transactional reservations.
- Paid By strings → typed bill-to party plus explicit workflow status.
- Email-based QBO identity → stored QBO Customer ID with controlled reconciliation.
- Knack formulas as rules → named, tested domain policies and database constraints.
- Fire-and-forget work → durable jobs with visible progress and retry state.
- Annual count formulas → unique constraints on subject + product family + membership year.
2.5 What should be preserved
QBO accounting authority
Preserve QBO invoice/payment IDs, customer mappings, item/class mappings, invoice numbering, and reconciliation. Carry forward historical DocNumbers for display, not as the only key.
Business distinctions
Preserve auditor vs firm payer, exam vs membership credit, per-auditor allocation under aggregate firm billing, inactive-member pricing, and firm eligibility exemptions.
Operational history
Preserve change requests, credit adjustments, who initiated/approved each action, payment dates, invoice documents, emails, and fulfillment links.
2.6 Improvements enabled by the custom application
| Area | Do better in the new app |
|---|---|
| Authorization | Enforce RBAC and firm/tenant ownership in every server command. Derive actor and firm from the session. Admin overrides require explicit permission and audit reason. |
| Pricing | Send only product/subject intent from the browser. Price and QBO mapping are selected server-side from versioned catalog data. Persist a price snapshot in integer cents and currency. |
| Idempotency | Use a unique idempotency key for every invoice request and QBO operation. Store QBO ID as soon as known. Repeated clicks/retries return the same job/result. |
| Atomicity | Commit request, charges, credit reservation, and outbox event in one database transaction. Use row locks or serializable operations for credit. Post/release reservations as jobs succeed/fail. |
| Asynchronous work | Run QBO/email/PDF work in a durable queue or worker, not inside a browser-dependent request. Expose job progress to the UI and operations staff. |
| Webhook safety | Verify against the raw body, persist event ID/payload hash, deduplicate, acknowledge quickly, then process via queue. Reconciliation remains the safety net. |
| Payment model | Project partial payments, multiple payments, voids, refunds, and write-offs. Derive paid status from allocated balance rather than only one Date Paid field. |
| Documents | Store one immutable PDF object with metadata and permission-based access. Do not copy the same asset pointer into admin/firm/auditor columns. |
| Secrets | Encrypt QBO refresh tokens at rest using a secrets manager/KMS-backed key; tightly restrict access and log token lifecycle events. |
| Observability | Structured events with correlation IDs across request, QBO invoice, payment, allocation, email, and fulfillment. Add a repair/replay console for failed integrations. |
| Rules | Implement eligibility as named server-side policy functions with reason codes. The UI displays those reasons but cannot bypass them. |
2.7 New responsibilities to be aware of
Application responsibilities
- Correct tenant isolation and financial authorization.
- Database migrations, constraints, backups, retention, and restore testing.
- Durable job execution, dead-letter handling, replay, and operational dashboards.
- Encryption and rotation of QBO credentials and webhook secrets.
- Explicit fulfillment policy and consistent downstream events.
- Audit logs that are tamper-evident and useful to Finance/support.
Integration responsibilities
- QBO API rate limits, token refresh races, timeouts, and eventual consistency.
- QBO customer merges, duplicate customers, changed emails, and inactive items.
- Webhook retries, duplicates, reordering, and missed events.
- Reconciliation of app totals against QBO balances and payment allocations.
- Historical data whose Knack state disagrees with QBO.
- Human Finance actions performed directly in QuickBooks.
2.8 Recommended migration sequence
Inventory the live Knack contract
Export object schema, formulas, record rules, view filters, page permissions, native emails/tasks, invoice types, active years, and role access. Write acceptance tests for each current creation path and downstream effect.
Build the local read model and reconciliation report
Import auditors, firms, products, invoice history, master/child/credit relationships, documents, and QBO references. Compare Knack paid state, QBO balance, credit totals, and child allocations; quarantine mismatches.
Introduce the new domain behind existing flows
Record BillingRequests, Charges, allocations, and integration jobs while Knack remains the UI. This validates the model and creates traceability before user-facing cutover.
Move one vertical slice at a time
Suggested order: auditor-paid single exam → auditor membership → firm batch new invoice → credit redemption → change/refund and reschedule fees. Each slice includes authorization, QBO issue, payment sync, document delivery, and fulfillment.
Cut over, reconcile, then retire
Stop new Knack writes, run a final delta import, reconcile against QBO, switch webhooks/jobs, and retain a read-only historical view. Remove legacy routes only after a measured stabilization window.
2.9 Implementation Decisions: Resolved, Provisional, and Open
4 resolved
2 provisional
1 partially resolved
Exam scheduling and progression
The current exam may be scheduled and taken before payment. Results are withheld until the invoice is fully paid, and the next exam’s invoice cannot be created until the previous exam invoice is paid.
Partial payments
Allocations and fulfillment are all-or-nothing. The full invoice must be paid before its connected balance or benefit can be used. Individual auditor lines are not paid proportionally.
Changes and cancellations
Value remains within the APSCA workflow as reusable internal credit or by reusing the previous invoice for the rescheduled exam date. Cash refunds through QBO remain explicit Finance exceptions unless policy changes.
Historical migration scope
Migrate future-scheduled exam invoices, open unpaid invoices, and unused firm credit as operational records. Completed inactive history may remain read-only, subject to retention requirements.
Credit accounting treatment
A “credit invoice” is believed to be an internal balance for future invoices—not a deposit, deferred-revenue instrument, or formal customer credit. Finance/client confirmation is required before selecting future QBO objects.
Batch invoice recipients
Delivery must be limited to authorized firm invoicing users. The current flow appears to send to the initiator; the client must confirm initiator-only delivery versus all designated invoicing contacts.
QuickBooks customer identity
Auditor customers are created when no QBO email match exists. Firm customers are manually created by APSCA and linked by a QBO customer ID stored on the firm. Still open: who may update or merge customers, and whether auditors need a stored QBO ID or another stable identifier instead of mutable email.
Evidence appendix
Source map
The following files are the main anchors used for this report. Line numbers reflect the repositories as reviewed on 13 July 2026.
apsca-server
routes/invoices.tscontrollers/mainRoutes/generateQBInvoiceFromKnack.tscontrollers/mainRoutes/helpers/getOrCreateQBCustomer.tscontrollers/generateBatchInvoices/index.tscontrollers/generateBatchInvoices/helpers/createMasterInvoice.tscontrollers/generateBatchInvoices/helpers/createChildInvoices.tscontrollers/generateBatchInvoicesCredit/index.tscontrollers/invoices/redeemCreditInvoice.tscontrollers/invoices/changeRequestStatusUpdate.tscontrollers/webhooks/handlePaymentCreationWebhook.tscrons/markInvoicesPaid/batchedHandler.tscrons/updateChildInvoices/handler.tscontrollers/proctor-u/services/invoiceFeeService.tscontrollers/Knack/knack_object_map.jsmiddleware/authenticateUser.jscontrollers/quickbooks/helpers/invoiceConstants.ts
apsca_knack
src/helpers/auditorGenExamInvoice/src/helpers/auditorGenMembershipInvoice/src/helpers/generateSingleInvoice/index.tssrc/helpers/invoiceForms/src/helpers/batchExamInvoicesApp/App.vuesrc/helpers/batchExamInvoicesApp/helpers/sanitizeAndFilterAuditors.tssrc/helpers/batchExamInvoicesApp/components/ExamInvoiceConfirmationPopup.vuesrc/helpers/batchExamInvoicesApp/components/MembershipInvoiceConfirmPopup.vuesrc/pages/views/view_1680_auditorGenExamInvoiceForm.tssrc/pages/views/view_1685_auditorGenMembershipInvoiceForm.tssrc/controllers/api_settings.tssrc/controllers/view_scene_map.ts