> Continu verbeteren van processen > Onkostenbeheer > Coupa Expenses > Datatemplate

Datatemplate voor onkostenbeheer

Coupa Expenses

Attributen voor onkostenbeheer(20) Activiteiten binnen onkostenbeheer(13) Extractiegidsen(2)

Datatemplate voor onkostenbeheer

Deze datatemplate biedt een vaste aanpak voor het analyseren van het onkostenbeheerproces in Coupa Expenses. Je vindt erin welke datavelden je verzamelt, welke belangrijke activiteiten je bijhoudt en hoe je de data kunt ophalen. Gebruik de template om alle benodigde informatie te verzamelen voor een grondige process mining-analyse.

Aanbevolen attributen voor een volledige dataverzameling
Belangrijke activiteiten binnen onkostenbeheer om bij te houden
Stapsgewijze uitleg voor het ophalen van data uit Coupa Expenses

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor onkostenbeheer

Dit zijn de aanbevolen datavelden voor je event log, zodat je het onkostenbeheerproces volledig kunt analyseren.

5 Verplicht 7 Aanbevolen 8 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	De naam van de bedrijfsgebeurtenis die op een bepaald moment bij een declaratie plaatsvond.
Beschrijving De activiteitsnaam beschrijft een specifieke stap of mijlpaal in het declaratieproces, zoals 'Declaratie ingediend', 'Goedgekeurd door manager' of 'Terugbetaling uitgevoerd'. Deze activiteiten vormen de knooppunten in de proceskaart en zijn de basis voor analyses van processtromen, bottlenecks en afwijkingen. Met dit attribuut kun je de volgorde van gebeurtenissen, de frequentie van processtappen en de overgangen ertussen analyseren. Het is nodig om de proceskaart op te bouwen, overgangstijden te berekenen en veelvoorkomende of niet-conforme procespaden te herkennen. Waarom dit belangrijk is Dit attribuut beschrijft de processtappen en maakt het mogelijk de processtroom te visualiseren en analyseren, de kern van process mining. Waar vind je dit? Dit wordt meestal afgeleid uit event logs, statuswijzigingen of auditsporen die horen bij het declaratieobject in Coupa. Mogelijk moet je statuscodes of gebeurtenistypen omzetten naar duidelijke namen. Voorbeelden Onkostendeclaratie ingediendGoedgekeurd door managerAfgewezen door financeTerugbetaling uitgevoerd
	Declaratie-ID ExpenseReportId	De unieke identificatiecode van een declaratie. Deze groepeert alle bijbehorende activiteiten en onkosten van één indiening.
Beschrijving De declaratie-ID is de belangrijkste identificatiecode van een case. Hiermee worden alle gebeurtenissen en activiteiten van één ingediende declaratie gegroepeerd. Elke declaratie krijgt bij het aanmaken een unieke ID. Zo kun je de volledige geschiedenis van een declaratie chronologisch volgen, van de eerste invoer tot de uiteindelijke betaling. Bij process mining gebruik je deze ID om het volledige verloop van elke declaratie te reconstrueren. Analisten kunnen processtromen visualiseren, verschillen tussen procespaden herkennen en metrieken per case berekenen, zoals de totale doorlooptijd en herstelrondes van afzonderlijke declaraties. Waarom dit belangrijk is Dit is de sleutel waarmee je alle gebeurtenissen van één declaratie aan elkaar koppelt. Zo kun je het hele proces van begin tot eind analyseren. Waar vind je dit? Dit is een primaire sleutel in de declaratieobjecten van Coupa. Je vindt deze vaak als 'id' of 'report-id' in het API-eindpunt Expense Reports of in de onderliggende tabellen. Voorbeelden ER-0012345ER-0012399ER-0013001
	Tijdstip van gebeurtenis EventTime	De timestamp die aangeeft wanneer een activiteit of gebeurtenis plaatsvond.
Beschrijving Het tijdstip van een gebeurtenis is de exacte datum en tijd waarop een activiteit in het systeem is vastgelegd. Deze timestamp is nodig om gebeurtenissen chronologisch te ordenen en tijdsanalyses uit te voeren. Zo zie je wanneer processtappen plaatsvinden en hoelang ze duren. Bij process mining gebruik je dit attribuut om de tijdlijn van elke case op te bouwen, de tijd tussen activiteiten te berekenen, vertragingen te herkennen en de totale doorlooptijd te meten. Het is belangrijk voor analyses van prestaties, naleving van service level agreements en patronen in de tijd, zoals bottlenecks. Waarom dit belangrijk is Deze timestamp bepaalt de chronologische volgorde van gebeurtenissen en vormt de basis voor analyses van duur en prestaties, waaronder doorlooptijden en het opsporen van bottlenecks. Waar vind je dit? Deze informatie staat in de auditsporen of event log-tabellen van Coupa, meestal bij de registratie van de activiteit of statuswijziging. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	Bronsysteem SourceSystem	Het systeem waar de data vandaan komt.
Beschrijving Dit attribuut geeft aan uit welke brontoepassing de eventdata afkomstig is. In dit geval is dat 'Coupa Expenses'. Het is belangrijk voor datagovernance en om data uit verschillende systemen van elkaar te onderscheiden in een proces dat meerdere systemen omvat. De herkomst van de data kan van belang zijn bij analyses van processen die door meerdere applicaties lopen. Waarom dit belangrijk is Geeft belangrijke context over de herkomst van de data, voor datagovernance, validatie en procesanalyses met meerdere systemen. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Coupa ExpensesCoupa
	Laatste data-update LastDataUpdate	De timestamp van de laatste data-update of extractie uit het bronsysteem.
Beschrijving Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit Coupa Expenses is gehaald en in de process mining-tool is geladen. Zo zie je hoe actueel de data is. Deze informatie helpt je te bepalen op welke periode de analyse betrekking heeft en of de dashboards de meest recente stand van zaken in de bedrijfsvoering weergeven. Het is belangrijke metadata voor datagovernance en voor het vertrouwen in de analyseresultaten. Waarom dit belangrijk is Laat zien hoe actueel de data is, zodat gebruikers weten op welke periode de analyse betrekking heeft en hoe relevant de resultaten zijn. Waar vind je dit? Deze timestamp wordt meestal aan het einde van een geslaagde data-import aangemaakt en opgeslagen door de data-extractie- of ETL-tool. Voorbeelden 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Afdeling medewerker EmployeeDepartment	De afdeling van de medewerker die de declaratie heeft ingediend.
Beschrijving Dit attribuut geeft aan bij welke afdeling of bedrijfseenheid de indiener van de declaratie hoort. De informatie komt meestal uit de stamgegevens van medewerkers. Dit is een belangrijke dimensie om de procesprestaties van verschillende onderdelen van de organisatie te vergelijken. Dashboards met goedkeuringstijden, afwijzingspercentages of beleidsovertredingen per afdeling gebruiken dit attribuut om te bepalen waar procesverbetering of gerichte training nodig is. Waarom dit belangrijk is Maakt het mogelijk prestaties tussen afdelingen te vergelijken en te zien welke onderdelen van de organisatie efficiënt werken en waar ondersteuning nodig is. Waar vind je dit? Haal deze informatie uit het profiel van de indiener in Coupa of koppel de gebruikers-ID aan een extern HR-systeem met stamgegevens. Zoek naar het veld 'department' in het gebruikersobject. Voorbeelden VerkoopMarketingTechniekFinanciën
	Eindtijd EndTime	De timestamp die aangeeft wanneer een activiteit is afgerond.
Beschrijving De eindtijd markeert het einde van een activiteit. In veel transactiesystemen is een activiteit een momentopname, waardoor de eindtijd gelijk is aan de starttijd. Bij activiteiten die een meetbare duur hebben, geeft dit attribuut aan wanneer ze zijn afgerond. Met dit veld bereken je de verwerkingstijd van afzonderlijke activiteiten nauwkeurig. Zo zie je beter waar tijd aan opgaat en kun je wachttijd onderscheiden van daadwerkelijke werktijd. Waarom dit belangrijk is Maakt het mogelijk de duur van activiteiten nauwkeurig te berekenen. Zo kun je analyseren hoeveel tijd specifieke taken kosten en hoeveel tijd er wordt gewacht. Waar vind je dit? Bij afzonderlijke gebeurtenissen is dit vaak hetzelfde als de starttijd (EventTime). Voor activiteiten met een duur moet je de waarde mogelijk uit een apart veld halen of afleiden van de timestamp van de volgende gebeurtenis. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	Gebruikersnaam UserName	De naam van de medewerker of gebruiker die de activiteit heeft uitgevoerd.
Beschrijving Dit attribuut geeft aan wie bij een specifieke gebeurtenis betrokken was, bijvoorbeeld wie een declaratie heeft ingediend, goedgekeurd of afgewezen. Het kan gaan om een naam, een personeelsnummer of een systeemaccount. Met een analyse per gebruiker kun je prestatiepatronen, de verdeling van de werklast en mogelijke opleidingsbehoeften herkennen. Dit attribuut is handig voor dashboards met metrieken per medewerker, bijvoorbeeld om goedkeuringstijden van verschillende managers te vergelijken. Waarom dit belangrijk is Koppelt activiteiten aan specifieke personen, zodat je de werklast, prestaties en het gedrag van medewerkers in het proces kunt analyseren. Waar vind je dit? Deze informatie staat meestal in de auditsporen van Coupa Expenses en is gekoppeld aan elke gebeurtenis of actie. Zoek naar velden zoals 'user-id', 'submitted-by' of 'updated-by'. Voorbeelden Jan Jansenjjansen11023
	Markering beleidsovertreding PolicyViolationFlag	Een booleaanse indicator die aangeeft of de declaratie is gemarkeerd wegens een beleidsovertreding.
Beschrijving Coupa kan onkosten automatisch markeren als ze in strijd zijn met het bedrijfsbeleid, bijvoorbeeld wanneer een uitgavenlimiet wordt overschreden of een niet-goedgekeurde leverancier wordt gebruikt. Dit attribuut geeft met waar of onwaar aan of er bij de declaratie een overtreding is vastgesteld. Deze markering is belangrijk voor het monitoren en analyseren van compliance. Je kunt er dashboards mee maken die beleidsovertredingen in de tijd en per afdeling bijhouden. Ook kun je vergelijken hoe declaraties met een beleidsovertreding worden afgehandeld, bijvoorbeeld of ze langer op goedkeuring wachten of vaker worden afgewezen. Waarom dit belangrijk is Maakt het mogelijk naleving van het beleid rechtstreeks te meten en analyseren, zodat je risico’s en terugkerende overtredingen kunt opsporen en aanpakken. Waar vind je dit? Dit is meestal beschikbaar als markering of status bij de declaratie of afzonderlijke onkostenregels in Coupa. Vaak wordt de waarde ingesteld door de regelsengine van het systeem. Voorbeelden truefalse
	Reden van afwijzing RejectionReason	De reden die een goedkeurder opgeeft bij het afwijzen van een declaratie.
Beschrijving Wanneer een manager of medewerker van Finance een declaratie afwijst, geeft die vaak een reden op. Dit attribuut legt die reden vast. Het kan gaan om een keuze uit een lijst of om vrije tekst. Dit attribuut is waardevol voor oorzaakanalyse. Door de meest voorkomende afwijsredenen te analyseren, kunnen organisaties zien waar beleid onduidelijk is, medewerkers extra training nodig hebben of het indieningsproces niet goed werkt. Zo kun je herstelwerk verminderen en het percentage declaraties dat in één keer wordt goedgekeurd verhogen. Waarom dit belangrijk is Laat zien waarom herstelwerk nodig is. Met gerichte training, duidelijker beleid of procesverbeteringen kun je afwijzingen verminderen. Waar vind je dit? Deze informatie staat meestal in de auditsporen of opmerkingen bij een afwijzing in Coupa. De reden kan in een apart veld staan of uit opmerkingen worden gehaald. Voorbeelden Bon ontbreektOnkosten buiten het beleidOnjuiste onkostencategorieDubbele indiening
	Status declaratie ExpenseReportStatus	De huidige of uiteindelijke status van de declaratie.
Beschrijving Dit attribuut geeft de eindstatus van de declaratie aan, bijvoorbeeld 'Goedgekeurd', 'Betaald', 'Afgewezen' of 'Ingetrokken'. Zo zie je hoe elke case is afgelopen. Bij analyses gebruik je de eindstatus om afgeronde cases te filteren en uitkomsten in te delen. Je kunt er afwijzingspercentages mee berekenen en zien welk aandeel van de declaraties elke mogelijke eindstatus bereikt. Ook helpt de status om declaraties te vinden die in een tussenstatus zijn blijven hangen. Waarom dit belangrijk is Geeft de uitkomst van elke case aan. Zo kun je bijvoorbeeld de procespaden van goedgekeurde en afgewezen declaraties vergelijken. Waar vind je dit? Dit is een primair statusveld van het declaratieobject in Coupa. Je vindt het in de kopgegevens; de waarde wordt tijdens het proces bijgewerkt. Voorbeelden wacht_op_goedkeuringgoedgekeurdbetaaldafgewezen
	Totaalbedrag TotalAmount	De totale geldwaarde van de declaratie.
Beschrijving Dit attribuut is de som van alle onkostenregels in de declaratie. Het is een belangrijke financiële maatstaf voor de waarde die door het proces loopt. Met het totaalbedrag kun je declaraties indelen in waardeklassen, die elk een andere goedkeuringsroute of controle kunnen hebben. Dashboards gebruiken dit attribuut om uitgavenpatronen te analyseren, declaraties met hoge bedragen op te sporen die bottlenecks kunnen veroorzaken en verbanden te leggen tussen de declaratiebedragen, verwerkingstijden en afwijzingspercentages. Waarom dit belangrijk is Geeft financiële context aan het proces. Zo kun je declaraties analyseren op basis van hun geldwaarde, die vaak invloed heeft op de goedkeuringsroute en prioriteit bij de verwerking. Waar vind je dit? Dit is een standaardveld in de kop van een declaratie in Coupa, vaak met de naam 'total' of 'total-amount'. Voorbeelden 150.752500.0085.50
	In één keer goedgekeurd IsFirstPassApproval	Een markering die aangeeft of de declaratie zonder afwijzingen of aanpassingen is goedgekeurd.
Beschrijving Dit berekende attribuut op caseniveau geeft aan of een declaratie bij de eerste poging door het goedkeuringsproces is gekomen. De waarde is 'true' als de case geen afwijzingen of activiteiten zoals 'Teruggestuurd voor aanpassing' bevat. Dit attribuut meet rechtstreeks hoe efficiënt het indienings- en goedkeuringsproces verloopt. Het vormt de basis voor de KPI voor het percentage declaraties dat in één keer wordt goedgekeurd. Door factoren te analyseren die samenhangen met een laag percentage, zoals de afdeling of onkostencategorie, kun je aanknopingspunten vinden voor procesverbetering. Waarom dit belangrijk is Geeft een duidelijke maatstaf voor de kwaliteit en efficiëntie van het proces. Zo kun je meten welk percentage van de declaraties zonder herstelwerk wordt verwerkt. Waar vind je dit? Dit wordt berekend op caseniveau. Je moet alle activiteiten voor een bepaalde ExpenseReportId doorlopen en controleren of er geen afwijzingen of herzieningen zijn. Voorbeelden truefalse
	Is herstelwerk IsRework	Een markering die aangeeft of een activiteit deel uitmaakt van een herstelronde, bijvoorbeeld wanneer een declaratie wordt teruggestuurd voor aanpassing.
Beschrijving Dit berekende booleaanse attribuut markeert activiteiten die herstelwerk vormen. Meestal krijgt het de waarde 'true' bij gebeurtenissen zoals 'Teruggestuurd voor aanpassing' en bij activiteiten die daarna in dezelfde case plaatsvinden. Herstelwerk opsporen is een belangrijk doel van process mining. Met deze markering kun je herstelwerk eenvoudig filteren en optellen. Je gebruikt de data om het herstelpercentage te berekenen, herstelrondes in de proceskaart te visualiseren en de oorzaken te analyseren van activiteiten die ervoor zorgen dat stappen opnieuw worden uitgevoerd. Waarom dit belangrijk is Markeert inefficiënte herstelrondes, zodat je eenvoudig kunt meten hoe vaak ze voorkomen, wat hun invloed op de doorlooptijd is en wat de oorzaken zijn. Waar vind je dit? Dit wordt berekend op basis van de processtroom. Je moet logica toepassen om activiteiten te herkennen die aangeven dat het proces teruggaat naar een eerdere fase, zoals 'Teruggestuurd voor aanpassing'. Voorbeelden truefalse
	Kostenplaats CostCenter	De kostenplaats waaraan de onkosten worden toegewezen.
Beschrijving De kostenplaats is een financiële dimensie voor boekhouding en budgettering. Deze geeft aan welk onderdeel van de organisatie de kosten draagt. De kostenplaats kan verschillen van de afdeling van de indiener. Met een analyse per kostenplaats bekijk je het proces vanuit financieel oogpunt. Je kunt uitgaven en procesefficiëntie volgen ten opzichte van specifieke budgetten of financiële eenheden. Dit is vooral nuttig voor Finance-teams die inzicht willen krijgen in de uitgaven van de organisatie en deze willen beheren. Waarom dit belangrijk is Voegt een belangrijke financiële dimensie toe aan de analyse, zodat je procesmetrieken rechtstreeks aan financiële eenheden en budgetten kunt koppelen. Waar vind je dit? Dit is een standaardboekhoudveld in Coupa. Je vindt het in de kop van de declaratie of op de onkostenregels. Het maakt vaak deel uit van het rekeningschema. Voorbeelden CC4510-MarketingCC2100-TechniekCC7800-Verkoop-Oost
	Land Country	Het land van de indienende medewerker of van de transactie.
Beschrijving Dit attribuut geeft aan welk land bij de declaratie hoort. Meestal is dit het land waar de indienende medewerker werkt. Het is een belangrijke dimensie voor procesanalyses in internationale organisaties. Met een analyse per land kun je prestaties, compliance en procesverschillen tussen regio’s vergelijken. Zo komen regionale verschillen in regelgeving, beleid of efficiëntie aan het licht die aandacht nodig hebben. Waarom dit belangrijk is Maakt het mogelijk procesprestaties en compliance tussen regio’s te vergelijken. Dat is belangrijk voor internationale organisaties. Waar vind je dit? Je kunt dit afleiden uit het gebruikersprofiel in Coupa of uit de juridische entiteit die bij de declaratie hoort. Voorbeelden USADEUGBRJPN
	Naam goedkeurder ApproverName	De naam van de manager of gebruiker van Finance die de declaratie heeft goedgekeurd of afgewezen.
Beschrijving Dit attribuut geeft aan wie betrokken was bij een goedkeuringsstap van een manager of Finance. Dit is niet dezelfde gebruiker als degene die de declaratie heeft ingediend. Met deze data kun je de prestaties en het gedrag van goedkeurders analyseren. Je kunt de doorlooptijd van goedkeuringen per persoon meten en bottlenecks opsporen die ontstaan doordat iemand te veel werk heeft of extra training nodig heeft. Dashboards kunnen helpen de werklast beter te verdelen en goedkeuringen efficiënter te laten verlopen. Waarom dit belangrijk is Helpt bottlenecks in de goedkeuringsketen op te sporen door vertragingen of hoge afwijzingspercentages aan specifieke goedkeurders te koppelen. Zo kun je gericht ingrijpen. Waar vind je dit? Je vindt dit in de goedkeuringsgeschiedenis of auditsporen van de declaratie in Coupa. Bij elke goedkeuringsstap hoort een registratie van de gebruiker die de actie heeft uitgevoerd. Voorbeelden Sanne de VriesDaan JansenWachtrij Finance-team
	Onkostencategorie ExpenseCategory	De categorie van de onkosten, zoals reizen, maaltijden of kantoorbenodigdheden.
Beschrijving Dit attribuut geeft aan om wat voor soort onkosten het gaat. Een declaratie kan meerdere onkostenregels bevatten, elk met een eigen categorie. Voor analyses per case kun je de meest voorkomende categorie gebruiken of de categorieën samenvoegen. Door het proces per onkostencategorie te bekijken, kun je verschillen in werkwijze of bottlenecks herkennen. Reiskosten kunnen bijvoorbeeld een ingewikkelder goedkeuringsroute volgen dan aankopen van kantoorbenodigdheden. Zo zie je hoe de aard van de onkosten het verloop van de verwerking beïnvloedt. Waarom dit belangrijk is Maakt het mogelijk het proces in te delen naar soort uitgaven, zodat je bottlenecks, beleidsregels en goedkeuringsroutes per categorie kunt herkennen. Waar vind je dit? Deze informatie staat op het niveau van de onkostenregels in Coupa. Voor analyses per case moet je de gegevens samenvoegen, bijvoorbeeld door de categorie van de regel met het hoogste bedrag te gebruiken. Voorbeelden VliegticketsMaaltijden en entertainmentSoftwareKantoorbenodigdheden
	Reden beleidsovertreding PolicyViolationReason	De specifieke reden waarom een declaratie is gemarkeerd wegens een beleidsovertreding.
Beschrijving Als een beleidsovertreding wordt gemarkeerd, geeft dit attribuut de specifieke reden aan, zoals 'Bedrag overschrijdt limiet' of 'Niet-goedgekeurde leverancier'. Dit geeft meer informatie dan een eenvoudige waar-of-onwaar-markering. Door de redenen voor beleidsovertredingen te analyseren, krijg je een gedetailleerder beeld van complianceproblemen. Je ziet welke beleidsregels vaak worden overtreden. Dat kan betekenen dat het beleid beter moet worden uitgelegd, moet worden aangepast of strikter moet worden gehandhaafd. Deze informatie helpt bij het opstellen van gerichte verbetermaatregelen voor compliance. Waarom dit belangrijk is Geeft details over complianceproblemen, zodat je gericht kunt werken aan betere naleving van het onkostenbeleid. Waar vind je dit? Deze informatie staat meestal bij de details van de beleidsmarkering of in de waarschuwingsmelding van de compliance-engine van Coupa. Voorbeelden Daglimiet voor maaltijden overschredenOnkostenpost is dubbelBon is verplicht
	Valuta Currency	De valutacode van het totaalbedrag van de declaratie.
Beschrijving Dit attribuut geeft aan in welke valuta het totaalbedrag van de declaratie is uitgedrukt, bijvoorbeeld USD, EUR of GBP. Deze context is nodig bij financiële data. Bij analyses van declaraties in een internationale organisatie is dit veld belangrijk om geldbedragen correct te interpreteren en op te tellen. Soms moet je alle bedragen omrekenen naar één basisvaluta om regio’s goed te kunnen vergelijken. Waarom dit belangrijk is Geeft de benodigde context bij geldbedragen, voor een correcte financiële analyse en het omrekenen van valuta in internationale rapportages. Waar vind je dit? Dit is een standaardveld in de kop van een declaratie in Coupa, meestal naast het veld voor het totaalbedrag. De naam is vaak 'currency-code'. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Activiteiten binnen onkostenbeheer

Leg deze belangrijke processtappen en mijlpalen vast in je event log voor een nauwkeurige ontdekking en analyse van de onkostenworkflow.

6 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Geboekt in de financiële administratie	De financiële transacties voor de declaratie worden geboekt in het grootboek. Vanuit financieel oogpunt is dit de laatste stap in het proces.
Waarom dit belangrijk is Dit is de laatste activiteit en markeert het daadwerkelijke einde van het proces. De tijd tussen de terugbetaling en de boeking is belangrijk voor een snelle en correcte financiële afsluiting. Waar vind je dit? Deze gebeurtenis wordt vastgelegd op basis van de boekingsdatum van de journaalpost of boekingsregels voor de declaratie. Deze worden beheerd via de boekhoudintegratie van Coupa. Vastleggen Uit het veld met de boekingsdatum op de boekingsregels voor de declaratie. Gebeurtenistype explicit
	Goedgekeurd door finance	Het finance- of auditteam geeft de definitieve goedkeuring voor de onkostendeclaratie. Dit betekent dat de declaratie is gecontroleerd en klaar is voor betaling. De gebeurtenis wordt vastgelegd in de goedkeuringsgeschiedenis.
Waarom dit belangrijk is Dit is de laatste goedkeuringsstap. De tijd tussen goedkeuring door de manager en goedkeuring door finance is een belangrijk deel van de totale goedkeuringsdoorlooptijd. Waar vind je dit? Vastgelegd op basis van de timestamp van de definitieve goedkeuringsactie in de gedetailleerde goedkeuringsgeschiedenis of het auditspoor van de onkostendeclaratie. Vastleggen Gebruik de timestamp van de definitieve goedkeuringsgebeurtenis in de goedkeuringsgeschiedenis van de onkostendeclaratie. Gebeurtenistype explicit
	Goedgekeurd door manager	De direct leidinggevende of eerste goedkeurder keurt de onkostendeclaratie goed. Dit wordt als expliciete gebeurtenis met timestamp vastgelegd in de goedkeuringsgeschiedenis van de declaratie.
Waarom dit belangrijk is Dit markeert het einde van de eerste goedkeuringsronde. De tijd tot deze gebeurtenis is belangrijk voor de KPI Doorlooptijd goedkeuring en voor het opsporen van bottlenecks bij managers. Waar vind je dit? Vastgelegd op basis van de timestamp van de goedkeuringsactie in de gedetailleerde goedkeuringsgeschiedenis of het auditspoor van de onkostendeclaratie in Coupa. Vastleggen Gebruik de timestamp van de goedkeuringsgebeurtenis in het logboek met de goedkeuringsgeschiedenis van de onkostendeclaratie. Gebeurtenistype explicit
	Onkostendeclaratie aangemaakt	Dit markeert het begin van de levenscyclus van een onkostendeclaratie. De gebeurtenis wordt vastgelegd wanneer een gebruiker voor het eerst een nieuwe declaratie aanmaakt en opslaat. De declaratie krijgt dan de status Concept.
Waarom dit belangrijk is Dit is het startpunt voor alle procesanalyses en belangrijk voor het meten van de totale doorlooptijd van begin tot eind. Waar vind je dit? Dit is een expliciete gebeurtenis, vastgelegd op basis van de timestamp waarop de declaratiekop in Coupa is aangemaakt. De bron is de timestamp 'created_at' in de tabel met declaratiekoppen. Vastleggen Gebruik de timestamp waarop het declaratieobject is aangemaakt. Gebeurtenistype explicit
	Onkostendeclaratie ingediend	De medewerker dient de ingevulde onkostendeclaratie formeel in ter goedkeuring. De declaratie verandert daarmee van de status Concept naar een status waarin goedkeuring wordt afgewacht. Het systeem registreert deze actie expliciet.
Waarom dit belangrijk is Dit is een belangrijk moment waarop de goedkeuringstijd begint. De tijd tussen aanmaak en indiening laat zien hoelang medewerkers nodig hebben om declaraties voor te bereiden. Waar vind je dit? Vastgelegd op basis van de indieningstimestamp in de declaratie zelf of de vermelding van de indiening in het auditspoor. Vastleggen Gebruik het timestampveld 'submitted_at' in de onkostendeclaratie. Gebeurtenistype explicit
	Terugbetaling uitgevoerd	De betaling is verwerkt en het geld is overgemaakt aan de medewerker. Deze gebeurtenis bevestigt dat de medewerker is betaald en dat het terugbetalingsdeel van het proces is afgerond.
Waarom dit belangrijk is Dit is een belangrijk moment voor de tevredenheid van medewerkers en het eindpunt voor de KPI Gemiddelde doorlooptijd terugbetaling. Waar vind je dit? Vastgelegd op basis van de uitvoeringsdatum van de betaling in het betaalrecord dat aan de onkostendeclaratie is gekoppeld. Dit gebeurt doorgaans in Coupa Pay of een gekoppeld systeem voor crediteurenadministratie. Vastleggen Gebruik de betaaldatum in het betaalrecord dat aan de onkostendeclaratie is gekoppeld. Gebeurtenistype explicit
	Afgewezen door finance	Het finance- of auditteam wijst de onkostendeclaratie af. Dit is een definitieve negatieve uitkomst, die als afwijzingsstatus wordt vastgelegd in de geschiedenis van de declaratie.
Waarom dit belangrijk is Door afwijzingen door finance te volgen, ontdek je ernstige problemen met compliance of documentatie die bij eerdere controles zijn gemist. Deze afwijzingen beïnvloeden de KPI voor het afwijzingspercentage. Waar vind je dit? Vastgelegd op basis van de timestamp van de afwijzingsactie door een goedkeurder van finance in het auditspoor van de onkostendeclaratie. Vastleggen Gebruik de timestamp van de afwijzingsgebeurtenis in het auditspoor tijdens de controle door finance. Gebeurtenistype explicit
	Afgewezen door manager	De manager van de medewerker wijst de onkostendeclaratie af. Vaak stopt het proces dan en gaat de declaratie terug naar de medewerker. Dit wordt als specifieke gebeurtenis vastgelegd in de goedkeuringsgeschiedenis.
Waarom dit belangrijk is Dit is een ongunstige uitkomst die laat zien waar het proces vastloopt. Analyse van deze gebeurtenissen is belangrijk voor het dashboard en de KPI voor het afwijzingspercentage van onkostendeclaraties. Waar vind je dit? Vastgelegd op basis van de timestamp van de afwijzingsactie in de goedkeuringsgeschiedenis of het auditspoor van de onkostendeclaratie. Vastleggen Gebruik de timestamp van de afwijzingsgebeurtenis in het logboek met de goedkeuringsgeschiedenis van de onkostendeclaratie. Gebeurtenistype explicit
	Beleidscontrole uitgevoerd	Er wordt automatisch gecontroleerd of de declaratie voldoet aan het onkostenbeleid van het bedrijf. Dit is doorgaans af te leiden uit de timestamp waarop voor het eerst een melding of waarschuwing voor een beleidsovertreding bij de declaratie wordt vastgelegd.
Waarom dit belangrijk is Dit is nodig voor het dashboard Compliance van het onkostenbeleid. Je ziet hiermee of en wanneer overtredingen in het proces worden ontdekt en wat de gevolgen zijn voor de goedkeuringstijd. Waar vind je dit? Af te leiden uit de timestamp waarop een melding van een beleidsovertreding wordt toegevoegd aan een onkostenregel of de declaratiekop. Vastleggen De timestamp waarop voor het eerst een melding van een beleidsovertreding wordt vastgelegd bij de onkostendeclaratie of een van de regels. Gebeurtenistype inferred
	Bonnetjes toegevoegd	Dit is de actie waarbij een gebruiker bonnetjes uploadt of toevoegt aan een onkostenregel in de declaratie. Je kunt dit vastleggen door te kijken wanneer bijbehorende bijlagen worden aangemaakt.
Waarom dit belangrijk is De timing en frequentie van deze activiteit kunnen patronen in gebruikersgedrag laten zien en mogelijke vertragingen door ontbrekende documentatie aan het licht brengen. Waar vind je dit? Afgeleid van de timestamp waarop bijlagen worden aangemaakt die aan de betreffende case-ID van de onkostendeclaratie zijn gekoppeld. Vastleggen Zoek de timestamps waarop bijlagen aan de onkostendeclaratie worden gekoppeld. Gebeurtenistype inferred
	Onkostendeclaratie ingetrokken	De medewerker trekt een ingediende onkostendeclaratie in voordat deze volledig is goedgekeurd. Daarmee wordt de lopende goedkeuringsprocedure geannuleerd. De actie wordt als expliciete gebeurtenis vastgelegd.
Waarom dit belangrijk is Hiermee zie je wanneer medewerkers zelf correcties aanbrengen of een indiening annuleren. Dat kan erop wijzen dat het proces onduidelijk is. Het is een onderbreking van het proces. Waar vind je dit? Vastgelegd na een expliciete actie van de gebruiker. De status wordt dan 'Ingetrokken' of 'Geannuleerd' en de actie wordt opgenomen in het auditspoor. Vastleggen Gebruik de timestamp van de actie 'intrekken' in het auditspoor van de onkostendeclaratie. Gebeurtenistype explicit
	Terugbetaling ingepland	Na de definitieve goedkeuring wordt de onkostendeclaratie toegevoegd aan een betaalbatch. Dit markeert de overgang van de goedkeuringsfase naar de betalingsverwerking.
Waarom dit belangrijk is Met deze activiteit begint de doorlooptijd van de terugbetaling. Vertragingen wijzen op achterstanden bij het overzetten van goedgekeurde declaraties naar het betaalsysteem. Waar vind je dit? Af te leiden uit een statuswijziging naar 'Betaling in afwachting' of de datum waarop de declaratie in Coupa Pay aan een betaalbatch wordt gekoppeld. Vastleggen De timestamp waarop de status verandert in 'Betaling in afwachting', of de aanmaakdatum van de bijbehorende betaalbatch. Gebeurtenistype inferred
	Teruggestuurd voor correctie	Een goedkeurder stuurt de declaratie terug naar de medewerker voor correcties, zonder de declaratie definitief af te wijzen. Hierdoor ontstaat een herstelwerkloop. Je kunt deze gebeurtenis afleiden uit een statuswijziging of een specifieke vermelding in het auditspoor.
Waarom dit belangrijk is Deze activiteit vormt de basis voor de analyse van herstelwerkloops. Als je weet waarom declaraties worden teruggestuurd, kun je trainingen verbeteren en het percentage declaraties verhogen dat meteen wordt goedgekeurd. Waar vind je dit? Af te leiden uit een statuswijziging naar bijvoorbeeld 'Correctie in afwachting' of 'Teruggestuurd'. Coupa kan deze actie ook expliciet vastleggen in de goedkeuringsgeschiedenis. Vastleggen De timestamp van de statuswijziging naar een status waarin correctie nodig is, of een specifieke gebeurtenis uit het auditlogboek. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Coupa Expenses

Stappen

Vereisten: Zorg voor een Coupa-gebruikersaccount met de benodigde rechten, meestal de rol Administrator of Integration Specialist, om geplande exports te openen en in te stellen. Je hebt ook toegang nodig tot een SFTP-server waar Coupa de geëxporteerde bestanden kan neerzetten.
Ga naar Geplande exports: Meld je aan bij Coupa. Open het menu Setup en klik onder Integrations op Scheduled Exports.
Stel de export van declaraties in: Klik op de knop 'Create'. Stel de eerste export in voor het object 'Expense Report'. Geef de export een duidelijke naam, zoals 'ProcessMind_Expense_Reports'. Kies 'CSV' als bestandsindeling. Selecteer in het gedeelte 'Fields' kolommen zoals id, created-at, submitted-at, updated-at, status, total, user-id en andere relevante attributen op declaratie-niveau.
Stel de export van goedkeuringsgeschiedenis in: Maak een tweede geplande export voor het object 'Expense Report Approval'. Noem deze 'ProcessMind_Expense_Approvals'. Neem velden op zoals id, created-at, updated-at, status, approver-id en expense-report-id. Dit object is belangrijk om goedkeurings-, afwijzings- en herzieningsgebeurtenissen vast te leggen.
Stel de export van bijlagen in: Maak een derde export voor het object 'Expense Report Attachment' en noem deze 'ProcessMind_Expense_Attachments'. Neem het tijdstip created-at en het bijbehorende expense-report-id of expense-line-id op om bij te houden wanneer bonnetjes zijn toegevoegd.
Stel de factuurexport voor betalingen in: Maak een vierde export voor het object 'Invoice from Expense Report'. Noem deze 'ProcessMind_Expense_Invoices'. Deze export is nodig om terugbetalingen en boekhoudkundige gebeurtenissen bij te houden. Neem velden op zoals expense-report-id, paid-date, scheduled-payment-date, exported en updated-at.
Stel de overdracht en planning in: Open voor elke export het tabblad 'Delivery'. Vul de verbindingsgegevens van de SFTP-server in, waaronder de host, gebruikersnaam en map. Stel de verificatiemethode in, meestal met een wachtwoord of sleutel. Kies op het tabblad 'Schedule' de frequentie 'Daily' voor regelmatige updates.
Voer exports uit en laad de data in: Activeer de planningen en voer ze zo nodig de eerste keer handmatig uit. Stel een geautomatiseerd proces in, zoals een ETL-script of een tool voor het laden van data in een datawarehouse, om de CSV-bestanden van de SFTP-server op te halen en in een stagingdatabase te laden.
Zet de data om naar een event log: Voer een transformatiescript uit op de stagingdata, bijvoorbeeld de meegeleverde SQL-query. Het script voegt data uit de verschillende tabellen (declaraties, goedkeuringen en facturen) samen tot één event log-tabel.
Exporteer voor ProcessMind: Exporteer de resulterende event log-tabel vanuit je database of datawarehouse naar één CSV-bestand. Zorg dat de kolomkoppen overeenkomen met de vereiste attributen, zoals ExpenseReportId, ActivityName en EventTime. Het bestand is nu klaar om te uploaden naar de process mining-tool.

Configuratie

Vereisten: Je hebt een actieve Coupa Expenses-module nodig. De gebruiker die de exports instelt, moet een rol hebben met rechten voor 'Scheduled CSV Exports'. Er moet een SFTP-server beschikbaar zijn. Zo nodig moet het IP-adres op de whitelist staan.
Belangrijke Coupa-objecten: Voor het ophalen van de data plan je exports in voor verschillende standaard Coupa-dataobjecten: 'Expense Report', 'Expense Report Approval', 'Expense Report Attachment' en 'Invoice from Expense Report'.
SFTP-instellingen: Geef de URL van de SFTP-server, de poort (meestal 22), inloggegevens voor een aparte gebruiker en de doelmap voor de bestanden op. Controleer in de Coupa-interface of de verbinding werkt.
Datumbereik en filters: Geplande exports bevatten doorgaans records die sinds de laatste geslaagde uitvoering zijn aangemaakt of bijgewerkt. Voor de eerste historische lading kun je een datumbereik voor 'created-at' of 'updated-at' instellen, bijvoorbeeld de afgelopen 6 tot 12 maanden.
Bestandsindeling: Gebruik altijd CSV. Deze indeling is eenvoudig en werkt met veel dataverwerkingstools.
Exportfrequentie: Voor process mining raden we een dagelijkse export aan, zodat de procesdata actueel blijft. Door de export buiten piekuren uit te voeren, beperk je mogelijke gevolgen voor de prestaties.

Voorbeeldquery sql

WITH last_update AS (
  SELECT CURRENT_TIMESTAMP AS last_data_update
)
SELECT
  er.id AS ExpenseReportId,
  'Expense Report Created' AS ActivityName,
  er."created-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Receipts Attached' AS ActivityName,
  att."created-at" AS EventTime,
  att."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_attachments att
JOIN stg_expense_reports er ON att.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Submitted' AS ActivityName,
  er."submitted-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er."submitted-at" IS NOT NULL

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Sent Back For Revision' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'sent_back'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Policy Check Performed' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.has_policy_violations = TRUE

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Withdrawn' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.status = 'withdrawn'

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Scheduled' AS ActivityName,
  inv.scheduled_payment_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.scheduled_payment_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Executed' AS ActivityName,
  inv.paid_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.paid_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Accounting Posted' AS ActivityName,
  inv.updated_at AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.exported = TRUE;

Stappen

Vereisten en omgeving instellen: Zorg dat Python 3.6 of hoger is geïnstalleerd. Installeer de benodigde bibliotheken: pandas voor dataverwerking en requests voor API-aanroepen. Voer hiervoor pip install pandas requests uit in je terminal. Vraag ook je Coupa-beheerder om een API-sleutel met leesrechten voor declaraties, onkostenregels, bijlagen en goedkeuringen.
Genereer een Coupa API-sleutel: Meld je aan bij Coupa. Ga naar Setup > Company Setup > API Keys. Maak een nieuwe API-sleutel aan en geef deze leesrechten voor de benodigde Expense-modules. Bewaar de sleutel veilig, want hiermee krijg je toegang tot de bedrijfsdata.
Initialiseer het Python-script: Maak een nieuw Python-bestand. Importeer de benodigde bibliotheken (requests, pandas, datetime). Definieer globale constanten voor de URL van je Coupa-omgeving (bijvoorbeeld https://[your_company].coupahost.com), de API-sleutel en de headers voor API-verificatie.
Stel het datumbereik en de API-parameters in: Geef de begin- en einddatum op voor de periode waaruit je data ophaalt. Gebruik deze als filters in de API-aanroepen om de hoeveelheid data te beperken. Stel ook de paginagrootte in, doorgaans 50 records per aanvraag bij Coupa.
Haal de declaratiekoppen op: Maak een functie die alle declaratiekoppen binnen het opgegeven datumbereik ophaalt. De functie moet paginering afhandelen door herhaaldelijk aanvragen te doen bij het endpoint /api/expense_reports. Verhoog daarbij de parameter offset totdat alle declaraties zijn opgehaald. Sla de declaratiekoppen op in een lijst.
Haal de detaildata op: Loop door elke declaratiekop uit de vorige stap. Doe voor elke declaratie aparte API-aanroepen voor de bijbehorende gegevens: goedkeuringen via /api/expense_reports/{id}/approvals en bijlagen via /api/expense_reports/{id}/attachments. Deze gegevens zijn nodig om het volledige event log samen te stellen.
Stel het event log samen: Maak een lege lijst voor de eventlogrecords. Zet de ruwe API-antwoorden tijdens het verwerken van declaraties en detaildata om naar gestandaardiseerde eventlogregels. Maak voor elk van de 13 vereiste activiteiten een dictionary voor één gebeurtenis en voeg die toe aan de lijst. Gebruik bijvoorbeeld het veld created-at voor de gebeurtenis 'Expense Report Created' en loop door de goedkeuringsdata om gebeurtenissen als 'Manager Approved' of 'Finance Rejected' aan te maken.
Koppel API-data aan attributen: Koppel in de transformatielogica de JSON-velden uit de Coupa API-antwoorden aan de vereiste en aanbevolen attributen. Koppel bijvoorbeeld id aan ExpenseReportId, created-at aan EventTime en total aan TotalAmount. Haal gebruikers- en afdelingsgegevens op uit de geneste gebruikersobjecten.
Verwerk afgeleide gebeurtenissen: Sommige activiteiten, zoals 'Reimbursement Scheduled' of 'Accounting Posted', zijn af te leiden uit statuswijzigingen. Gebruik het veld status van de declaratie en het tijdstempel updated-at om deze gebeurtenissen aan te maken. Een statuswijziging naar 'processing_payment' kun je bijvoorbeeld vastleggen als de activiteit 'Reimbursement Scheduled'.
Maak het DataFrame en exporteer de data: Zet de lijst met gebeurtenissen om naar een pandas DataFrame zodra alle declaraties zijn verwerkt en de lijst is gevuld. Voeg vaste kolommen toe, zoals SourceSystem en LastDataUpdate. Exporteer het DataFrame tot slot met de methode to_csv naar een CSV-bestand en stel index in op False. Dit CSV-bestand is klaar om te uploaden naar ProcessMind.

Configuratie

Rechten voor de API-sleutel: De API-sleutel voor verificatie moet minimaal alleen-lezen toegang hebben tot de volgende Coupa-objecten: Expense Reports, Expense Lines, Users, Approvals en Attachments.
URL van de Coupa-omgeving: Geef de basis-URL van de Coupa-omgeving van je bedrijf op, bijvoorbeeld https://your-company.coupahost.com. Dit is de basis voor alle API-endpointaanroepen.
Filters voor datumbereik: Filter de data op een specifieke periode om de prestaties en de hoeveelheid data beheersbaar te houden. Gebruik de queryparameters created-at[gt] (groter dan) en created-at[lt] (kleiner dan). Een gebruikelijk startbereik is 3 tot 6 maanden aan data.
Paginagrootte: De Coupa API geeft per aanvraag doorgaans maximaal 50 records terug. Het script moet deze limit verwerken en de parameter offset gebruiken om alle volgende pagina's op te halen.
Statusfilters: Je kunt de selectie verder beperken door een status-filter toe te voegen aan de eerste query voor declaratiekoppen. Je kunt bijvoorbeeld alleen declaraties met de status 'approved', 'paid' of 'denied' ophalen.
Aandachtspunten voor prestaties: Het script doet meerdere API-aanroepen voor elke declaratie. Bij tienduizenden declaraties kan het ophalen van de data veel tijd kosten. Voer het script buiten piekuren uit of laad alleen wijzigingen op basis van het tijdstempel updated-at.

Voorbeeldquery python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_URL = class="hl-string">"https://[your_company].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SSZ (UTC)
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># API request headers
HEADERS = {
    class="hl-string">"Accept": class="hl-string">"application/json",
    class="hl-string">"X-COUPA-API-KEY": API_KEY
}

class=class="hl-string">"hl-comment"># Static values for the event log
SOURCE_SYSTEM = class="hl-string">"Coupa Expenses"
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to fetch all pages for a given API endpoint."""
    all_data = []
    offset = 0
    limit = 50
    while True:
        params[class="hl-string">'offset'] = offset
        params[class="hl-string">'limit'] = limit
        try:
            response = requests.get(endpoint, headers=HEADERS, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            if not data:
                break
            all_data.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
    return all_data

def main():
    class="hl-string">"""Main function to extract, transform, and save expense data."""
    print(class="hl-string">"Starting expense report extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch all expense report headers in the date range
    reports_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports"
    reports_params = {
        class="hl-string">"created-at[gt]": START_DATE,
        class="hl-string">"created-at[lt]": END_DATE,
        class="hl-string">"fields": class="hl-string">"["idclass="hl-string">", "created-atclass="hl-string">", "updated-atclass="hl-string">", "submitted-atclass="hl-string">", "withdrawn-atclass="hl-string">", "statusclass="hl-string">", "totalclass="hl-string">", "userclass="hl-string">", "exportedclass="hl-string">", "expense-linesclass="hl-string">", "policy-violationsclass="hl-string">"]"
    }
    expense_reports = get_paginated_data(reports_endpoint, reports_params)

    print(fclass="hl-string">"Found {len(expense_reports)} expense reports to process.")

    class=class="hl-string">"hl-comment"># 2. Process each expense report to create events
    for i, report in enumerate(expense_reports):
        print(fclass="hl-string">"Processing report {i+1}/{len(expense_reports)}: ID {report['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        base_event = {
            class="hl-string">'ExpenseReportId': report[class="hl-string">'id'],
            class="hl-string">'TotalAmount': float(report.get(class="hl-string">'total', 0.0)),
            class="hl-string">'ExpenseReportStatus': report.get(class="hl-string">'status'),
            class="hl-string">'EmployeeDepartment': report.get(class="hl-string">'user', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name') if report.get(class="hl-string">'user', {}).get(class="hl-string">'department') else None,
            class="hl-string">'SourceSystem': SOURCE_SYSTEM,
            class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
            class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># EndTime can be populated if duration is meaningful
            class="hl-string">'RejectionReason': None, class=class="hl-string">"hl-comment"># Will be populated by rejection events
            class="hl-string">'PolicyViolationFlag': bool(report.get(class="hl-string">'policy-violations'))
        }

        class=class="hl-string">"hl-comment"># Event: Expense Report Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Expense Report Created',
            class="hl-string">'EventTime': report[class="hl-string">'created-at'],
            class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
        })
        
        class=class="hl-string">"hl-comment"># Event: Expense Report Submitted
        if report.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Submitted',
                class="hl-string">'EventTime': report[class="hl-string">'submitted-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># Event: Expense Report Withdrawn
        if report.get(class="hl-string">'withdrawn-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Withdrawn',
                class="hl-string">'EventTime': report[class="hl-string">'withdrawn-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })
        
        class=class="hl-string">"hl-comment"># Event: Policy Check Performed (inferred)
        if base_event[class="hl-string">'PolicyViolationFlag']:
             event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Policy Check Performed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Using updated-at as a proxy timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># 3. Fetch attachments for class="hl-string">'Receipts Attached' event
        attachments_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/attachments"
        attachments = get_paginated_data(attachments_endpoint, {})
        if attachments:
            first_attachment_time = min(att[class="hl-string">'created-at'] for att in attachments if class="hl-string">'created-at' in att)
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Receipts Attached',
                class="hl-string">'EventTime': first_attachment_time,
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># 4. Fetch approvals for approval/rejection events
        approvals_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/approvals"
        approvals = get_paginated_data(approvals_endpoint, {})
        
        is_first_approval = True
        for approval in sorted(approvals, key=lambda x: x[class="hl-string">'updated-at']):
            activity = None
            rejection_reason = approval.get(class="hl-string">'reason')
            
            if approval[class="hl-string">'status'] == class="hl-string">'approved':
                activity = class="hl-string">'Manager Approved' if is_first_approval else class="hl-string">'Finance Approved'
                is_first_approval = False
            elif approval[class="hl-string">'status'] == class="hl-string">'rejected':
                activity = class="hl-string">'Manager Rejected' if is_first_approval else class="hl-string">'Finance Rejected'
                is_first_approval = False
            elif approval[class="hl-string">'status'] in [class="hl-string">'sent_back', class="hl-string">'pending_resubmit']:
                activity = class="hl-string">'Sent Back For Revision'

            if activity:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': approval[class="hl-string">'updated-at'],
                    class="hl-string">'UserName': approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname'),
                    class="hl-string">'RejectionReason': rejection_reason
                })
        
        class=class="hl-string">"hl-comment"># 5. Infer payment and accounting events from status
        if report[class="hl-string">'status'] == class="hl-string">'processing_payment':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Scheduled',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })
            
        if report[class="hl-string">'status'] == class="hl-string">'paid':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Executed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># class="hl-string">'exported' flag indicates posting to an ERP system
        if report.get(class="hl-string">'exported') == True:
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Accounting Posted',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

    class=class="hl-string">"hl-comment"># 6. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated. Exiting.")
        return
        
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ExpenseReportId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'UserName',
        class="hl-string">'EmployeeDepartment', class="hl-string">'TotalAmount', class="hl-string">'ExpenseReportStatus',
        class="hl-string">'RejectionReason', class="hl-string">'PolicyViolationFlag', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate'
    ]
    df = df[column_order]
    df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTime'], inplace=True)
    
    output_filename = class="hl-string">'coupa_expense_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Klaar om aan de slag te gaan?

Gebruik deze template om te beginnen met process mining en waardevolle inzichten in het onkostenbeheer te krijgen. Begin vandaag nog met het verbeteren van je processen.

Terug naar de verbetergids

Template downloaden

Verbeter onkostenbeheer: pak vertragingen vandaag aan

Spoor inefficiënties op en verkort de doorlooptijd van onkosten met 30% dankzij een helder overzicht.

Start je gratis proefperiode

Je hebt geen creditcard nodig. Je kunt binnen enkele minuten aan de slag.

Datatemplate voor onkostenbeheer

Datatemplate voor onkostenbeheer

Attributen voor onkostenbeheer

Activiteiten binnen onkostenbeheer

Extractiegidsen

Geplande exports van Coupa via SFTP voor onkostendata

Stappen

Configuratie

Voorbeeldquery sql

Python-script voor onkostendata via de Coupa REST API

Stappen

Configuratie

Voorbeeldquery python

Klaar om aan de slag te gaan?

Verbeter onkostenbeheer: pak vertragingen vandaag aan