Finance × Member Experience v1 · fix Salesforce first, then connect the systems

Paying for Event Expenses

One invoice, four systems, twenty-plus human touches. Most of the fix is inside a system we already control.

V1 · SALESFORCE ONLY

Stop asking humans for what Salesforce already knows

Auto-fill from the Campaign Project ID, retire the double-entry Accounting section, generate the packet, lock the record at approval. No integrations, no vendor decision required.

V2 · CONNECT THE SYSTEMS

Let NetSuite and the AP tool talk to Salesforce

Payee sync, PO creation, invoice creation from the packet, and "paid" flowing back — once we know whether we're staying on Stampli or moving to Rippling.

Two versions, one direction. Click through to see the path. →

Today

One event invoice touches four systems and two teams — 21 steps end to end, 23 when the payee is new.

Member Experience submits in Salesforce; Accounting re-codes and approves; a paper packet is hand-assembled; NetSuite gets the payee and PO; Stampli runs review, approval and payment; then someone clicks back into Salesforce to mark it paid.

Step —

Human touch System step Only when the payee is new (rare) hover any step for detail

0

Human touches · every invoice

0

Systems

0

Fields keyed by hand

0×

Same data entered

Where the friction lives

Four things make this slow — and three of them are Salesforce habits, not system limits.

✍️Double entry

Member Experience keys event code, gathering type, GL account, group, department, experience code. Accounting then re-keys the same list — plus location, subsidiary, account and account ID — into a separate section on the same record.

Salesforce habit

📎The hand-built packet

Before anything reaches Stampli, Accounting grabs the PDF invoice, prints the reviewed Salesforce page, and saves the approval email — three artifacts assembled by hand, per invoice, mostly so there's a link back to the record.

Salesforce habit

🔓Records that drift

Nothing locks after approval. It's not uncommon for an amount or expense code to change after Accounting has signed off — which means a Chatter thread, a second record for the difference, or a reclass in NetSuite.

Salesforce habit

🔗IDs that don't line up

When a payee is new — which is rare — ME creates it in Salesforce and Finance re-types it into NetSuite by hand (the old sync stopped working). Bigger issue: many vendor IDs originally loaded into NetSuite were wrong, so every invoice includes a manual "does the payee ID match?" check.

Integration problem

Three of the four biggest sources of friction sit entirely inside Salesforce. We own Salesforce. That's the v1 opportunity.

The insight

The Campaign Project ID already knows almost everything we ask people to type.

Every event invoice hangs off a Campaign Project — the source of truth for event code, gathering type, group, department, experience code, subsidiary and location. Today two teams re-type it. The only field that truly needs a human is the expense code, because it requires reading the invoice.

Fields keyed by hand today0 fields

→

After v115 keyed · rest auto-filled

Typed by ME or Accounting Still typed (needs a human) Auto-filled from Campaign Project ID

V1 · Salesforce only

Five changes, all inside Salesforce, none waiting on another system.

These are the green notes on the process map. Every one of them is configuration and workflow we control today.

1

ME submits four things: expense code, amount, payee, PDF.Everything else — event code, gathering type, GL account, group, department, experience code — pre-populates from the Campaign Project ID.

Fields keyed15 → 4

2

Retire the separate Accounting re-code section.Location, subsidiary, account and account ID derive from the same source. Accounting reviews and approves; it no longer re-types.

Double entryGone

3

Auto-generate the packet on approval.PDF invoice + snapshot of the approved record + approval stamp with a link back, produced by Salesforce and delivered by download or email. No printing, no hunting for the email.

Manual artifacts3 → 0

4

Lock the record at approval.Amount and coding can't change after Accounting signs off. If something really is wrong, ME submits a follow-up record for the difference — the way Accounting already prefers.

After-the-fact editsBlocked

5

Investigate and simplify the "Invoice Added to Accounting" checkbox and the ME / Finance section split.Working theory: the checkbox exists for ME reporting only. If so, it becomes a status, not a click.

Extra clicksRemoved

Nothing here needs NetSuite, Stampli or Rippling to change. It can ship in a normal delivery cycle.

V1 · The result

Same four systems, but the Salesforce half of the journey collapses.

The steps that disappear are the ones inside Salesforce, and the ones that stay get lighter — ME only enters what the invoice itself tells them. Downstream — NetSuite, the AP tool — is untouched and waits for the vendor decision.

Step —

Human touch System step Only when the payee is new (rare) Simplified in v1 Removed in v1

0 → 0

Human touches · every invoice

0 → 0

Steps in Salesforce

0 → 0

Fields keyed by hand

0

Integrations required

The gate

V2 waits on one decision: Stampli or Rippling.

Every integration on the AP side — packet upload, invoice creation, "paid" flowing back — is built against a specific tool. We shouldn't invest in Stampli plumbing if the tool is about to change. V1 doesn't have this problem, which is why it goes first.

Now

Ship v1

Salesforce-only changes. Independent of the AP tool. Real relief for ME and Accounting immediately.

Decision

Stampli or Rippling?

Finance settles the AP platform. Until then, no new build against Stampli.

Then

Build v2

Integrations to NetSuite and the chosen AP tool, on settled ground.

Can start now

NetSuite-side work is largely tool-agnostic: fixing the broken payee sync, auditing vendor IDs, and understanding the existing SF→NetSuite PO sync (set up by a consultant; appears to be a nightly pull, can be triggered manually).

Waits for the decision

Anything that touches the AP tool: automatic packet upload, invoice creation, PO referencing, and pushing "paid" back to Salesforce. Same design either way — different plumbing.

V2 · Connect the systems

Two human decisions. Everything else moves on its own.

ME submits. Accounting approves. From there, the payee, PO, packet, invoice and payment status flow between systems without anyone re-typing, uploading, or clicking back to mark something paid.

Salesforcewhere the humans are

NetSuiteledger & POs

AP toolStampli or Rippling

Human touch Automated by integration

The AP approval chain stays a human process — that's a control, not friction. What v2 removes is the copying between systems.

The end state

Submit. Approve. Paid.

Member Experience describes the expense once. Accounting makes one decision. The systems carry it the rest of the way and tell Salesforce when it's done.

🧾

ME submits

Expense code, amount, payee, PDF. Everything else auto-fills from the Campaign Project.

✅

Accounting approves

One review, one click. Record locks. Packet, payee and PO generate themselves.

💸

Systems pay & report back

AP tool runs its own review and pays. Salesforce flips to Paid automatically.

19 → 14 → 10

Human touches per invoice · today / v1 / v2

15 → 4

Fields keyed by hand

1×

Data entered

0

Integrations needed for v1

Fix Salesforce first. Then connect the systems we've decided to keep.

V1 ships on our own timeline. V2 follows the Stampli / Rippling decision.