John Glasgow, administrerende direktør, finansdirektør og grunnlegger av Campfire – intervjuserie

John Glasgow er administrerende direktør, finansdirektør og grunnlegger av Campfire. Han har erfaring fra finans, fusjoner og oppkjøp innen teknologi og selskapsstrategi. Før han grunnla selskapet, jobbet han hos Adobe, Invoice2go og Bill.com, blant annet med å lede Invoice2go gjennom oppkjøpet på 625 millioner dollar. Arbeidet hans i økonomiavdelinger har formet ønsket om å erstatte prosesser som er avhengige av regneark, med regnskapssystemer som beholder detaljene på transaksjonsnivå og støtter automatisering.

Campfire utvikler en KI-basert ERP-plattform for økonomi- og regnskapsteam. Plattformen samler hovedbok, automatisering av inntektsføring, rapportering og håndtering av regnskapsavslutning. Ember-agentene arbeider med de underliggende regnskapsdataene for å støtte oppgaver som avstemming og kategorisering av transaksjoner, mens Forecast skiller mellom bokførte faktiske tall, forpliktede beløp og KI-genererte estimater. I dette intervjuet snakker Glasgow om arkitekturen bak KI-basert regnskap, grensene mellom agentenes autonomi og menneskelig godkjenning, og hvordan økonomiteam kan opprettholde sporbarhet etter hvert som automatiseringen øker.

Karrieren din har omfattet finans, fusjoner og oppkjøp innen teknologi og strategi hos Adobe, Invoice2go og Bill.com, før du grunnla Campfire. Hva så du gjentatte ganger i økonomiavdelinger som overbeviste deg om at den underliggende ERP-løsningen måtte bygges på nytt, i stedet for bare å forbedres med enda et programvarelag?

Salget av Invoice2go til Bill.com for 625 millioner dollar viste meg problemet på nært hold. Under selskapsgjennomgangen håndterte jeg over 500 forespørsler i regneark, fordi inntektsregnskapet, SaaS-rapporteringen og konsolideringene våre lå der i stedet for i et system. Et selskap av den størrelsen utførte fortsatt kritiske økonomioppgaver i regneark.

I Bill, der jeg ledet strategiske partnerskap og jobbet tett med finansdirektøren, så jeg det samme problemet hos kundene. Lønn, utgiftsstyring og leverandør- og kundereskontro var blitt modernisert, men økonomiteamene måtte fortsatt bruke et ERP-system som var bygget for en tidligere tid.

Problemet ligger i selve hovedboken. Eldre ERP-systemer mottar sammendragsposteringer fra fakturering, betalinger, lønn og andre systemer, så transaksjonsdetaljene er borte når informasjonen når hovedboken. Det manglende datagrunnlaget kan ikke gjenopprettes ved å legge til enda et programvarelag. Jeg ønsket en hovedbok som beholdt detaljene og kunne utføre arbeidet, noe som innebar å bygge ERP-systemet på nytt fra grunnen av.

«KI-basert» er i ferd med å bli en vanlig beskrivelse av programvare for bedrifter. Hva er det arkitektonisk sett som gjør et KI-basert ERP-system fundamentalt forskjellig fra et tradisjonelt ERP-system som legger til en stor språkmodell eller KI-assistent oppå et eksisterende system?

Den grunnleggende forskjellen er at et KI-basert ERP-system er bygget rundt dataene KI-arbeidsflyter trenger for å utføre oppgaver.

En KI-assistent kan bare lese det et eldre ERP-system lagrer. Hvis ERP-systemet inneholder månedlige sammendrag i stedet for detaljer på transaksjonsnivå, kan KI finne et tall eller utarbeide en forklaring, men den kan ikke på en pålitelig måte avstemme transaksjoner eller kontoer eller forklare hvordan en postering ble opprettet. Campfire beholder alle transaksjonsdetaljene og har ansvar for både hovedboken og underbøkene, slik at Ember-agentene får dataene de trenger for faktisk å utføre arbeidet.

En annen forskjell er sporbarheten. Hver handling agentene utfører, er knyttet til de underliggende hovedbokdataene og kan gjennomgås før den bokføres.

Den tredje forskjellen er selve modellen: Campfires Accounting Intelligence er trent på regnskapsdata og skriver kode for å utføre økonomioppgaver, noe som gjør resultatene reproduserbare. Det er dette som gjør at agentene kan handle, i stedet for bare å komme med forslag.

Campfire lanserte nylig Forecast, som deler inneværende måned inn i faktiske, forpliktede og KI-estimerte tall, i stedet for å be KI forutsi hele perioden. Hvorfor utformet du løsningen på denne måten, og hvor mener du KI virkelig er nyttig i økonomiske prognoser, sammenlignet med områder der deterministiske regnskapsdata bør være styrende?

Som finansdirektør spør jeg hvor måneden vil ende, fem eller flere dager før den er over, og da er mye allerede kjent. Hvis KI skulle forutsi hele perioden, ville kjente tall blitt erstattet med gjetninger. Derfor deler Forecast måneden inn i tre lag:

Faktisk: det som allerede er bokført i hovedboken.

Forpliktet: kjente framtidige beløp fra kontrakter, regninger, eiendeler og leieavtaler som ennå ikke er bokført.

Estimert: Embers prognose for den delen som faktisk er ukjent, basert på selskapets historikk og sesongvariasjoner.

Det er her jeg mener KI hører hjemme i prognosearbeidet: i den delen ingen ennå kan vite. Deterministiske regnskapsdata bør styre alt som allerede er kjent. Hvis man blander de to, blir det vanskeligere å skille fakta fra estimater. Da kan man heller ikke vite hvilke tall man kan stå inne for når prognosen legges fram for styret.

Når noen spør hvordan jeg kom fram til tallet, kan jeg åpne hvilken som helst verdi og vise de faktiske, forpliktede og estimerte delene, sammen med Embers forutsetninger. Forecast gir råd; ingenting av det løsningen produserer, bokføres automatisk i hovedboken. Den gir imidlertid økonomiteamet et tidlig varsel om hvor måneden er på vei, slik at det blir mulig å ta forretningsbeslutninger før måneden er omme.

Forecast lar Ember anslå den ukjente delen av måneden ved hjelp av historiske trender og sesongvariasjoner, samtidig som løsningen forklarer forutsetningene bak anslagene. Hvordan håndterer dere situasjoner der historiske mønstre plutselig ikke lenger er nyttige, for eksempel ved rask vekst, tap av en stor kunde, et oppkjøp eller en annen uvanlig hendelse?

Det er i slike måneder en CFO trenger en prognose aller mest, og derfor er den delt inn i lag. Det er bare den estimerte delen av Forecast som avhenger av historiske trender og sesongvariasjoner. Det forpliktende laget bygger på kontrakter, regninger, eiendeler og leieavtaler som allerede finnes i Campfires hovedbok, så et oppkjøp, tap av en kunde eller rask vekst endrer ikke det som allerede er kjent.

Når mønsteret endrer seg, vet økonomiteamet som regel hvorfor før det gjenspeiles i dataene, og kan derfor legge til konteksten. De kan skrive et notat om hva som har endret seg, legge ved noe som en bemanningsplan eller koble til en datakilde, for eksempel et CRM- eller HRIS-system, via MCP-integrasjonen vår. Ember bruker denne konteksten til å beregne den ukjente delen på nytt.

Hvert anslag inneholder også en forklaring på én setning av forutsetningene, slik at jeg kan vise hva som er fakta, hva som er forpliktet, og hva som er en prognose når jeg legger fram prognosen.

Campfire har utviklet sin egen store regnskapsmodell, Large Accounting Model (LAM), i stedet for å basere seg helt på generelle modeller. Hva har dere lært om begrensningene ved generelle KI-modeller innen regnskap, og hva må en spesialisert modell forstå som en vanlig LLM typisk ikke gjør?

Regnskap krever svar som kan gjenskapes, ikke svar som bare virker sannsynlige. Generelle modeller er gode til å generere tekst, men kan ha problemer med tallresonnering og regnskapsmessig klassifisering, der de samme inndataene må gi samme svar hver gang.

I stedet for å be en modell resonnere direkte over finansdata, lar vi den skrive SQL eller Python-kode som utfører arbeidet. Kode gir reproduserbare resultater, noe som er viktig ved revisjon, og gjør det mulig for selskaper å automatisere handlinger uten at noen må godkjenne hvert identiske resultat.

Vår Accounting Intelligence er trent på regnskapsdata og forstår blant annet hvordan en kontoplan er bygget opp, mønstre hos leverandører og hvordan et ryddig regnskap ser ut. Den lærer også av hver kundes transaksjonshistorikk. Nøyaktigheten avhenger like mye av systemet rundt modellen som av selve modellen.

Økonomiteam har uvanlig liten toleranse for KI-feil. Når agenter begynner å utføre avstemminger, kategorisere transaksjoner, klargjøre posteringer og samhandle med hovedboken, hvor bør grensen gå mellom autonom utførelse og godkjenning fra mennesker?

Grensen bør avhenge av om handlingen kan kontrolleres. Hvis en postering kan gjenskapes og spores tilbake til de underliggende dataene i hovedboken, bør ikke en person måtte godkjenne hvert enkelt tilfelle. Hvis den ikke kan forklares eller gjenskapes, bør en person gjennomgå den før den bokføres.

Slik har vi bygget Ember. Hver handling utført av en agent loggføres, spores tilbake til de underliggende dataene i hovedboken og kan gjennomgås. Teamene setter konfidensgrenser som avgjør hva Ember håndterer autonomt, og hva som sendes videre til en person. De kan utvide graden av autonomi etter hvert som resultatene skaper tillit.

Mennesker har fortsatt ansvaret for vurderingene. Regnskapsførerne bestemmer hvor mye Ember skal håndtere, gjennomgår avvik og forklarer hvorfor tallene har endret seg. Agentene tar seg av det repetitive arbeidet med matching, merking og avstemming. TwelveLabs er et godt eksempel: Med tre regnskapsførere som dekker USA og Korea halverte selskapet tiden det tok å avslutte regnskapet, og sparte over 300 000 dollar.

Campfire har også lansert en MCP-butikk som lar Ember samhandle med eksterne systemer, for eksempel betalings-, CRM-, innkjøps- og HR-plattformer. Ser du for deg at ERP-systemet etter hvert blir mindre av et passivt system for registrering og mer av et orkestreringslag der KI-agenter kan arbeide på tvers av hele den finansielle teknologistakken?

Ja, så lenge hovedboken fortsatt er det autoritative regnskapssystemet. Historisk sett registrerte ERP-systemet arbeid som ble utført andre steder, så de fleste svarene finnes utenfor hovedboken: en fornyelse i CRM-systemet, en nyansatt i HRIS-systemet eller en innkjøpsordre i innkjøpssystemet. Hvis agenter skal utføre arbeidet, trenger de også denne konteksten, så ERP-systemet må kobles direkte til disse systemene.

Økonomiteam har laget prognoser på denne måten i årevis ved å hente salgsmuligheter fra CRM-systemet og bemanningstall fra HRIS-systemet. Med Forecast gjør Ember dette når et team har koblet til systemene, mens hovedboken fortsatt er sannhetskilden for alt som allerede er kjent. Hovedboken forblir sannhetskilden, mens agenter kan arbeide på tvers av systemene rundt den.

Du har et særlig interessant perspektiv på KI-økonomi, siden du både er CEO og CFO i et KI-selskap som betjener andre økonomiteam. Hvordan ser budsjetteringen for KI ut blant selskaper i dag, og tror du prisingen av KI for bedrifter vil gå bort fra abonnementer per bruker og over til betaling etter bruk, resultater eller en annen modell?

Vi ser at budsjettene flyttes fra faste kostnader per bruker til variabelt KI-forbruk, og mange økonomiteam er ennå ikke rigget for det. Når agenter overtar arbeid som mennesker tidligere utførte, kan selskaper få behov for færre menneskelige brukerlisenser samtidig som KI-bruken øker. Leverandørene legger også til forbrukskreditter og overforbruksgebyrer oppå brukeravgiftene, så økonomiteam må beregne mulige forbrukskostnader før de signerer.

Jeg forventer at hybridmodeller blir vanligere enn ren resultatbasert prising. Som CFO ønsker jeg en forutsigbar grunnpris, mens jeg som CEO trenger en prising som gjenspeiler den faktiske bruken.

Campfire hentet inn 35 millioner dollar i en serie A-runde, etterfulgt av 65 millioner dollar i en serie B-runde bare noen uker senere. Hva endret seg i markedet eller i kundenes etterspørsel i løpet av denne perioden, slik at dere bestemte dere for å finansiere selskapet så offensivt, og hvor ser du den største muligheten for at denne kapitalen kan bidra til å fremskynde produktutviklingen?

Vi hadde stor etterspørsel allerede før serie A-runden, men responsen tok seg umiddelbart opp etter at den ble avsluttet. Selskaper tok kontakt for å få demonstrasjoner, mange av dem hadde ikke brukt Campfire før, og det ble tydelig at etterspørselen var større enn vi hadde planlagt for.

Det ga oss muligheten til å investere mer offensivt for å møte etterspørselen, særlig etter hvert som selskaper ble villige til å gå bort fra eldre plattformer som NetSuite og Sage Intacct. Kunder som Replit viser hvorfor: Selskapet vokste fra 10 millioner til over 200 millioner dollar i årlige gjentakende inntekter uten å utvide regnskapsteamet på fire personer, og avslutningen av inntektsregnskapet gikk fra å ta åtte timer til 30 minutter.

Vi hentet inn 35 millioner dollar i serie A-runden, ledet av Accel, etterfulgt av en serie B-runde på 65 millioner dollar, der Accel og Ribbit var medledere. Dermed hentet vi inn totalt 100 millioner dollar på 12 uker. Vi har brukt kapitalen til å holde tritt med etterspørselen, og har vokst fra 10 ansatte til over 150 i San Francisco, New York og London.

Regnskap utviklet med KI som utgangspunkt har raskt blitt en konkurranseutsatt kategori, der selskaper som Campfire og Rillet utfordrer etablerte plattformer som QuickBooks, NetSuite og Sage Intacct. Hvis vi ser fem år fram i tid, hvilke deler av regnskap og ERP forventer du at KI-agenter vil håndtere nesten fullstendig, og hvilke ansvarsområder vil fortsatt ligge fast hos menneskelige finansmedarbeidere?

Jeg forventer at agenter vil håndtere det meste av rutinearbeidet: å koble transaksjoner til betalinger, kategorisere transaksjoner, avstemminger, periodiseringer og de mekaniske delene av månedsavslutning og rapportering. Det er repetitivt, regelbasert arbeid som programvare kan lære seg.

Det som fortsatt vil være menneskers ansvar, er skjønn og ansvarlighet. Regnskapsførere vil avgjøre hvor mye agentene kan håndtere selvstendig, gjennomgå unntak, forklare hvorfor tallene har endret seg og gi virksomheten råd om hva den bør gjøre videre. Noen må fortsatt stå til ansvar for regnskapet.

Over tid vil «KI-basert fra grunnen av» bli en grunnleggende forventning til økonomiprogramvare. Det som vil skille løsningene fra hverandre, er om økonomiteamene stoler på systemet med hovedboken sin, og om de kan se nøyaktig hvordan systemet kom fram til konklusjonene sine. Det er dette nivået vi utviklet Campfire for å nå, og allerede bruker over 400 selskaper, deriblant Cursor, Clay, Polymarket og PostHog, til å føre regnskapet sitt.

Takk for et flott intervju. Lesere som ønsker å lære mer om regnskap utviklet med KI som utgangspunkt og ERP, kan besøke Campfire.