ScopeLedger

• 

  Client chat changes separated into quoted, confirmed and unconfirmed scope.

• 

  Real PayPal sandbox state: the same invoice is PAID, with $1,240 paid and $0 due.

Inspiration

A freelancer quotes a logo and brand guidelines. The client approves the logo, asks for two extra posters, and mentions a banner without deciding. Those requests sit in a chat thread, while the invoice needs a clear list of agreed work. ScopeLedger connects the conversation to that bill.

What it does

Paste the chat beside the fixed quote. The model proposes quoted, confirmed and unconfirmed lines, with the client's words beside each change. Review the evidence and total before billing. Original quote prices stay fixed, the server computes the total in integer cents, and unconfirmed requests are excluded. Missing prices become questions.

Create a real PayPal sandbox invoice draft, send it, open its PayPal payment page, then read the payment status back into ScopeLedger. Repeating an invoice action with the same scope reuses the same invoice. Refreshing the browser restores the saved scope and checks PayPal again.

How we built it

Next.js 16, React 19, Vercel AI SDK 7 and an OpenAI-compatible language model. PayPal operations use the official agent-toolkit, with a small adapter from its AI SDK v4 tool schema to v7.

A server-signed scope receipt binds billing actions to the reviewed lines. PayPal's invoice number, actual state and stable request IDs support recovery after a lost response or service restart. Local request coalescing handles concurrent clicks; PayPal remains the source of invoice state. The demo supports USD and sandbox payments. Saved browser sessions expire after 24 hours.

Challenges we ran into

The toolkit can return a structured error without throwing, so the application checks those error envelopes explicitly. Creating an invoice and receiving its response are separate events: if the response is lost, retrying must first look for the existing invoice. Sending also checks the actual PayPal state before issuing another operation. A redirect alone is never treated as payment proof.

Accomplishments

The recorded walkthrough follows one real sandbox invoice from DRAFT through SENT to PAID, with $1,240 paid and $0 due. Duplicate actions, browser refresh and service restart recovery were checked against the same invoice. The recording uses fictional client material and sandbox funds.

24 unit tests cover billing rules, changed receipts, expiry, invoice ownership, concurrent creation, and simulated lost-response recovery. Typecheck, lint and production build pass. The live browser flow verifies actual PayPal state transitions rather than mock responses.

What we learned

The language model proposes an interpretation. A person reviews it, server code fixes the billing payload, and PayPal confirms what happened to the invoice. Keeping those responsibilities explicit made both the product and its failure paths easier to test.

What's next

Evaluate a wider set of ambiguous client chats with human reviewers, especially contradictory prices and changes that sound approved but lack clear confirmation.

Built With

• nextjs
• paypal-agent-toolkit
• react
• typescript
• vercel-ai-sdk
• vitest