Click anywhere to close
Two ways in. Practitioners work by assignment and are the knowledge behind every worker. Staff build and run the company, and there will never be many of them. Both are listed here when open.
Specialists from any desk on the roster, engaged by assignment, hours on a ledger, a quality record that is yours.
Postings are English documents. Each says what the role owns, what it needs, and who it reports to.
You build and own the layer between a worker and a client's systems: the adapters that read and write SAP, Oracle, NetSuite, Dynamics and the rest, and the execution discipline that makes every write idempotent, verified and audited. It is the part of the platform a client's security review opens first and a bank's auditor reads last.
A Humetry worker does not advise; it acts. It parks an invoice, releases a payment proposal, posts a receipt, creates a credit memo request, in the client's own ERP, under an identity the client's administrators provisioned. Every one of those writes has to be safe to repeat, provable after the fact, and impossible outside the scope the client delegated. That layer does not yet exist in the form it needs to. You will build it, and for a while you will be it.
The work is unglamorous in the way that matters. An idempotency key or a transaction identifier where the system allows one, and a documented substitute where it does not. A status check after every timeout and before any retry, because a write that timed out may have landed. The resulting document re-read from the system and recorded, so the record says what the system says and not what we hoped. One adapter interface, one adapter at a time, each built against the vendor's sandbox before any client is in sight, each carrying the same guarantees. The first is SAP; the order after that follows the first engagements.
You will sit in client security reviews and answer for the integration identity, its scopes, its secrets and its audit lines. You will be on the call when a write is ambiguous at two in the morning in the client's time zone, and you will write the incident record a controller can read. You report to the founder, work beside the engagement owner and the practitioners, and are the engineering department for as long as it takes to earn a second engineer. Success looks like this: a client's auditor reads the trail of a case without us in the room, and finds nothing to ask.
The engineer who builds the worker itself: the runtime that takes a desk's procedures, the client's authority rules and the lessons learned, puts a model to work over them, and lets it act only through the platform's checks. The scientist decides what a worker knows; you build the machine that runs it, case after case, all day.
Between a model and a client's ERP stands the worker runtime: the loop that picks up a case, reads the evidence, follows the desk's procedure, decides, asks the platform whether it may act, acts through an adapter, re-reads the result and writes the record. It has to run thousands of cases a day across twenty-three desks, stop cleanly when it must, escalate when no rule resolves a case, and leave a trail a controller can read. It does not exist yet. You will build it, and you will be the one who knows why it did what it did.
The work is the discipline of a system that acts. A procedure engine that follows written procedures faithfully and surfaces where they are silent. A tool layer that exposes an adapter's reads and writes to the model only within the identity's scopes. An authority check that runs before every write and cannot be reasoned around. A case state machine in which a case waiting on someone is open and never complete. A record writer that chains every entry. Cost and latency you can predict per case, and a harness that replays any case from its record. You will choose the model interface so that a desk's model can be swapped when the researcher's measurements say so.
You will work with the founding engineer who owns the adapters, the scientist who decides what a worker learns, the researcher who measures it and the expert who attacks it. You report to the founder. Success looks like this: the first worker runs accounts payable against a vendor sandbox end to end, every case it closed can be replayed from its record, and the second desk takes a week, not a quarter.
The scientist who decides how a worker is taught: how a practitioner's correction becomes a scoped, versioned, tested lesson, how a desk's procedures are represented so a model follows them and a controller can read them, and which model runs which desk. You own the method by which the workforce gets better without ever learning a transaction right.
A Humetry worker is not a prompt. It is a desk's procedures, the client's authority rules, the lessons learned on that engagement, and a model that reasons over them, held inside a platform that decides what it may do. The quality of the first three is the company's moat, and the method for building them does not yet exist in a form that scales from one desk to twenty-three. You will build that method.
The central problem is scope. When a worker was wrong about one supplier's unit of measure, the correction must become a lesson about that supplier, for that client, in those dates, and never a rule for every supplier. You will design how lessons are represented, bounded, versioned, tested on cases the worker has never seen and on the cases it already got right, deployed, and watched; and how procedures are written so that a model follows them faithfully and a controller can read what the worker will do. You will decide, desk by desk, which model runs it and how that choice is measured, and you will change your mind when the measurement says so.
You will work with the practitioners who approve lessons, the researcher who measures the workers, and the engineers who run them. You report to the founder. Success looks like this: a desk that has run for a quarter is better than it was, every improvement can be traced to a correction a named practitioner made, and nothing the worker learned ever widened its authority.
The researcher who measures the workers: the historical evaluation before a pilot, the gates during it, the scorecard every week after, and the drift nobody noticed. You decide what complete means in numbers, and you are the reason a client can trust them.
Every engagement passes four gates, each a threshold the worker must clear on cases it has never seen, judged by severity. Every week after that, a scorecard reads five measures against their thresholds, and the renewal decision in week sixteen rests on them. Those numbers are worth exactly what the method behind them is worth. You will own the method.
You will design how historical cases are sampled, held back and marked with the practitioners; how accuracy is read by severity rather than by count; how autonomous completion is measured so that a case waiting on a person is never counted complete; how a worker's reading drifts over weeks and how that drift is caught before a client catches it. You will study failures the way a safety engineer does: by class, by cause, by what the record shows the worker read before it acted. You will publish the method to clients in plain words, because a measure nobody can read is not a measure.
You will work with the scientist who teaches the workers, the engagement owners who present your scorecards, and the practitioners who mark the cases. You report to the founder. Success looks like this: a client's controller reads the week's scorecard, understands every number on it, and finds that it matches what their own people saw.
The person who attacks the workers before anyone else does: instructions hidden in invoices and emails, authority boundaries, the write protocol under failure, the walls between client environments. You own the adversarial side of the control page, and the evidence a security review asks for.
A Humetry worker reads documents all day: invoices, remittances, emails, portal messages. Every one is a channel through which someone might try to tell the worker what to do. The platform's rule is that documents are evidence, not instructions, and that a worker holds exactly the authority the client delegated. A rule is only as good as the attacks it has survived. You will run the attacks.
You will build the adversarial case sets: injected instructions in every form a supplier or customer could send, attempts to reach a reserved action through a permitted one, writes that time out at the worst moment, two sources that disagree in ways designed to mislead, and the cross-client probes that must find nothing. You will run them against every desk before it enters a client environment and again at every release, in vendor sandboxes first. You will write the findings into the control description a client's security review reads, and you will sit in that review.
You will work with the engineer who owns identity and the write protocol, the scientist who owns what a worker learns, and the researcher who measures it. You report to the founder. Success looks like this: an attack that would have moved money is caught in a sandbox, written up, turned into a regression case, and never seen in production.
The one named person a client holds accountable for the service: the scope, the thresholds by severity, the four stages and their gates, the decisions inbox, the weekly report, the incidents, and the conversation when something is wrong. You have run a finance tower or audited one, and you can tell a reasonable answer from a correct one.
Every Humetry engagement has one accountable owner, with a named backup and a documented handover. The owner is not a project manager and not an account manager. The owner is the person who agreed with the client's process owner what complete means, case by case and severity by severity, and who answers for whether the workers met it this week.
The engagement runs in four stages, historical evaluation, shadow operation, supervised production, recurring service, each with a gate and a threshold the worker must clear on cases it has never seen. You run discovery and process mapping, write the service description and the acceptance thresholds, and present the scorecard at each gate. You read the weekly report before the client does. You classify every intervention honestly: a capability failure goes to engineering, a policy gap goes back to the client's owner, a data problem is named as one. You never let a case that is waiting on someone be called complete.
When a client corrects a worker, you turn the correction into a proposed lesson with an explicit scope, because a rule for one supplier must never become a rule for every supplier, and you put it in front of the practitioners who approve it. When something goes wrong, you own it until it is resolved and you say so in writing. You report to the founder. The first engagement is run with the founder beside you; the second is yours.
A practitioner assignment, not a staff role. You are the human judgment behind a worker's exceptions and the historical cases it is evaluated on: you decide, you write the reason every time, and your corrections become tested lessons. Hours on a ledger, a quality record that is yours.
A worker on an accounts payable, cash application or deductions desk escalates the cases no rule resolves: a supplier asserting an agreement not on record, a deduction without a reason, two sources that disagree. Those cases come to you. You decide them against the client's policy and the contract, you record the reason in words a controller would accept, and you close them. Before a pilot, you mark the held-back cases the worker will be scored on, by outcome and by severity, so the thresholds mean something.
The scope of a correction is yours to set. When a worker was wrong about one supplier's unit of measure, the lesson is about that supplier, that client, those dates, and you narrow any proposal that reaches further. You approve lessons, narrow them, or send them back, and the platform tests each one on cases it has never seen before it is deployed.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your tower first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker that builds and checks changes in a client's SAP finance: you keep the client's process book true, you read every specification before anything is built, and the decisions the worker is not allowed to take come to you.
Humetry's workers carry a defined change to a verified end inside a client's SAP, within the authority the client delegated, and prove it. The first class of change is validations, a check at a document event that stops or warns. The worker recognises the requirement, reads the client's settings, writes a specification against a closed schema, and the build is rendered from the approved specification the client's way. What the worker cannot do is know the client's finance the way you do.
You hold the client's process book: the document events their rules hook into, the company codes and document types in scope, the tolerances and substitutions a request may really be asking for, and the regression documents that must still post afterwards. You read each specification and say whether it is the right change. A request that is a tolerance, a substitution, an authorisation or a report is referred, with where it goes, before anything is built, and you are the person it is referred to. In quality you check the documents the case names, before and after, and your acceptance is what moves the change on. On ECC, S/4HANA on premise and both cloud editions.
London anchors the assignment in the United Kingdom: the finance functions and shared-service centres of UK corporates, on their change windows and in their time zone, on site in the City or Canary Wharf when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the developer behind a worker that writes ABAP in a client's custom packages: you review what it built, you hold the release to quality that the worker is never allowed to take, and when the worker's hands do not reach, yours do.
A Humetry worker builds inside a client's development system through SAP's own developer interfaces: it creates the transport, writes the implementation in the client's custom package, runs the unit tests and the code checks, and records every write with the grant that allowed it. Two locks stand over it: Humetry's Interlocking, which refuses anything the client's application owner did not sign for, and the client's own SAP roles. Releasing a transport to quality is reserved to a person. On this assignment that person is you.
You review the worker's code the way you would review a junior's, against the client's standards and the specification the functional specialist accepted; you release what is right and send back what is not, with the reason on the record. Where the worker's route does not yet reach, a classic BAdI hook-up, a parameter set, a check that needs the system's own hand, you build it in the client's package and the worker takes it from there. Classic ABAP on ECC and S/4HANA on premise; ABAP Cloud and released APIs on the Public Edition.
London anchors the assignment in the United Kingdom: the finance functions and shared-service centres of UK corporates, on their change windows and in their time zone, on site in the City or Canary Wharf when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker on a client's Dynamics 365 Finance: the payables exceptions it resolves, the configuration it proposes, and the decisions it is not allowed to take. You know vendor invoices, posting profiles and workflow the way the worker never will.
Humetry's workers take ownership of defined work inside a client's Dynamics 365 Finance. The first assignment there is payables exceptions: invoices that fail matching, vendors asserting an agreement not on record, approvals that stall in workflow, posting profiles and settlement that disagree with the ledger. The worker investigates, proposes, acts within its grant, and escalates what no rule resolves.
You hold the client's process book for Dynamics: legal entities and vendor groups in scope, the matching and tolerance policy, the invoice workflow and who approves what, the posting profiles, the number sequences, and the periodic jobs that must still run afterwards. You decide the escalated cases against the client's policy and the contract, in words a controller would accept. When a change to configuration is proposed, you read it before it is built and test it in the sandbox before it is promoted. Dynamics 365 Finance first; Business Central where a client runs it.
London anchors the assignment in the United Kingdom: the finance functions and shared-service centres of UK corporates, on their change windows and in their time zone, on site in the City or Canary Wharf when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker that builds and checks changes in a client's SAP finance: you keep the client's process book true, you read every specification before anything is built, and the decisions the worker is not allowed to take come to you.
Humetry's workers carry a defined change to a verified end inside a client's SAP, within the authority the client delegated, and prove it. The first class of change is validations, a check at a document event that stops or warns. The worker recognises the requirement, reads the client's settings, writes a specification against a closed schema, and the build is rendered from the approved specification the client's way. What the worker cannot do is know the client's finance the way you do.
You hold the client's process book: the document events their rules hook into, the company codes and document types in scope, the tolerances and substitutions a request may really be asking for, and the regression documents that must still post afterwards. You read each specification and say whether it is the right change. A request that is a tolerance, a substitution, an authorisation or a report is referred, with where it goes, before anything is built, and you are the person it is referred to. In quality you check the documents the case names, before and after, and your acceptance is what moves the change on. On ECC, S/4HANA on premise and both cloud editions.
Zurich anchors the assignment in Switzerland: the finance functions of Swiss corporates, pharmaceutical groups, insurers and banks, where the specification is read before anything is built and the regulator may read it afterwards. German with English, on their change windows and in their time zone, on site in Zurich or Basel when a client asks for it.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the developer behind a worker that writes ABAP in a client's custom packages: you review what it built, you hold the release to quality that the worker is never allowed to take, and when the worker's hands do not reach, yours do.
A Humetry worker builds inside a client's development system through SAP's own developer interfaces: it creates the transport, writes the implementation in the client's custom package, runs the unit tests and the code checks, and records every write with the grant that allowed it. Two locks stand over it: Humetry's Interlocking, which refuses anything the client's application owner did not sign for, and the client's own SAP roles. Releasing a transport to quality is reserved to a person. On this assignment that person is you.
You review the worker's code the way you would review a junior's, against the client's standards and the specification the functional specialist accepted; you release what is right and send back what is not, with the reason on the record. Where the worker's route does not yet reach, a classic BAdI hook-up, a parameter set, a check that needs the system's own hand, you build it in the client's package and the worker takes it from there. Classic ABAP on ECC and S/4HANA on premise; ABAP Cloud and released APIs on the Public Edition.
Zurich anchors the assignment in Switzerland: the finance functions of Swiss corporates, pharmaceutical groups, insurers and banks, where the specification is read before anything is built and the regulator may read it afterwards. German with English, on their change windows and in their time zone, on site in Zurich or Basel when a client asks for it.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker on a client's Dynamics 365 Finance: the payables exceptions it resolves, the configuration it proposes, and the decisions it is not allowed to take. You know vendor invoices, posting profiles and workflow the way the worker never will.
Humetry's workers take ownership of defined work inside a client's Dynamics 365 Finance. The first assignment there is payables exceptions: invoices that fail matching, vendors asserting an agreement not on record, approvals that stall in workflow, posting profiles and settlement that disagree with the ledger. The worker investigates, proposes, acts within its grant, and escalates what no rule resolves.
You hold the client's process book for Dynamics: legal entities and vendor groups in scope, the matching and tolerance policy, the invoice workflow and who approves what, the posting profiles, the number sequences, and the periodic jobs that must still run afterwards. You decide the escalated cases against the client's policy and the contract, in words a controller would accept. When a change to configuration is proposed, you read it before it is built and test it in the sandbox before it is promoted. Dynamics 365 Finance first; Business Central where a client runs it.
Zurich anchors the assignment in Switzerland: the finance functions of Swiss corporates, pharmaceutical groups, insurers and banks, where the specification is read before anything is built and the regulator may read it afterwards. German with English, on their change windows and in their time zone, on site in Zurich or Basel when a client asks for it.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker that builds and checks changes in a client's SAP finance: you keep the client's process book true, you read every specification before anything is built, and the decisions the worker is not allowed to take come to you.
Humetry's workers carry a defined change to a verified end inside a client's SAP, within the authority the client delegated, and prove it. The first class of change is validations, a check at a document event that stops or warns. The worker recognises the requirement, reads the client's settings, writes a specification against a closed schema, and the build is rendered from the approved specification the client's way. What the worker cannot do is know the client's finance the way you do.
You hold the client's process book: the document events their rules hook into, the company codes and document types in scope, the tolerances and substitutions a request may really be asking for, and the regression documents that must still post afterwards. You read each specification and say whether it is the right change. A request that is a tolerance, a substitution, an authorisation or a report is referred, with where it goes, before anything is built, and you are the person it is referred to. In quality you check the documents the case names, before and after, and your acceptance is what moves the change on. On ECC, S/4HANA on premise and both cloud editions.
Singapore anchors the assignment in Asia Pacific: the regional headquarters and shared-service centres that run finance for a dozen countries from one place, on their change windows and in their time zone, on site in Singapore when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the developer behind a worker that writes ABAP in a client's custom packages: you review what it built, you hold the release to quality that the worker is never allowed to take, and when the worker's hands do not reach, yours do.
A Humetry worker builds inside a client's development system through SAP's own developer interfaces: it creates the transport, writes the implementation in the client's custom package, runs the unit tests and the code checks, and records every write with the grant that allowed it. Two locks stand over it: Humetry's Interlocking, which refuses anything the client's application owner did not sign for, and the client's own SAP roles. Releasing a transport to quality is reserved to a person. On this assignment that person is you.
You review the worker's code the way you would review a junior's, against the client's standards and the specification the functional specialist accepted; you release what is right and send back what is not, with the reason on the record. Where the worker's route does not yet reach, a classic BAdI hook-up, a parameter set, a check that needs the system's own hand, you build it in the client's package and the worker takes it from there. Classic ABAP on ECC and S/4HANA on premise; ABAP Cloud and released APIs on the Public Edition.
Singapore anchors the assignment in Asia Pacific: the regional headquarters and shared-service centres that run finance for a dozen countries from one place, on their change windows and in their time zone, on site in Singapore when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.
A practitioner assignment, not a staff role. You are the functional judgment behind a worker on a client's Dynamics 365 Finance: the payables exceptions it resolves, the configuration it proposes, and the decisions it is not allowed to take. You know vendor invoices, posting profiles and workflow the way the worker never will.
Humetry's workers take ownership of defined work inside a client's Dynamics 365 Finance. The first assignment there is payables exceptions: invoices that fail matching, vendors asserting an agreement not on record, approvals that stall in workflow, posting profiles and settlement that disagree with the ledger. The worker investigates, proposes, acts within its grant, and escalates what no rule resolves.
You hold the client's process book for Dynamics: legal entities and vendor groups in scope, the matching and tolerance policy, the invoice workflow and who approves what, the posting profiles, the number sequences, and the periodic jobs that must still run afterwards. You decide the escalated cases against the client's policy and the contract, in words a controller would accept. When a change to configuration is proposed, you read it before it is built and test it in the sandbox before it is promoted. Dynamics 365 Finance first; Business Central where a client runs it.
Singapore anchors the assignment in Asia Pacific: the regional headquarters and shared-service centres that run finance for a dozen countries from one place, on their change windows and in their time zone, on site in Singapore when a client asks for it and from where you work the rest of the time.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your field first; the qualification is the only unpaid work.